I'm working on an ASP.NET MVC project and I've come to the point where I want to start considering my caching strategy. I've tried to leave my framework as open as possible for the use in caching.
From what I heard during Scott Hanselman's podcast StackOverflow.com uses page output caching and zips that content and puts it into RAM. This sounds like this would be great for user-wide cache but for something like personalized pages you would have to cache a version for each user and that could get out of control very quickly.
So, for a caching strategy. Which should be used, Output Caching, Data Caching or combined? My first thoughts are both but as far as cache dependencies it sounds like it could get a bit complex.
We're doing API and Output caching on a large scale (3 milion visits a day) web site (news portal). The site is primarily used by anonymous users, but we do have authenticated users and we cache a complete site just for them, due to some personalized parts of the site, and I must admit that we had absolutely no problems with memory pressure.
So, my advice would be cache everything you can in API cache so your Output cache rebuilding is even faster.
Of course, pay close attention to your cache ratio values in the performance counters. You should see numbers >95% of cached hits.
Another thing to pay attention is cache invalidation, this is a big issue if you have a lot of related content. For example, you cache music stuff and information about one album or song might be displayed and cached on few hundred pages. If anything changes in that song, you have to invalidate all of these pages which can be problematic.
Bottom line, caching is one of the best features of ASP.NET, it's done superbly and you can rely on it.
Be careful about over-aggressive caching. Although caching is a tool for helping performance, when used incorrectly, it can actually make performance worse.
I can't answer whether output caching or data caching would work for you better without knowing more details about your project.
I can help provide a couple examples of when to use one over another.
If you have a specific data set which you would use often in many different views, you'd be better off using data caching. You'd use this if your data fetch operation was very common and expensive relative to your data rendering. If you had multiple views which used the same data, you would save your data fetching time.
If you had a view which used a very specific data set and the rendering of the view was complicated and this view was requested very often (for example, stack overflow's home page), then you would benefit a lot from output caching.
So in the end, it really depends on your needs and be careful about using caching incorrectly.
Related
When designing a ASP.net WebForm application what are some important steps to take (or hacks if you like to use the term) to ensure the best possible performance (in terms of speed, stability, and scalability)?
Avoid round trips to server
Wherever possible user AJAX calls.
Implement Caching.
Avoid using Viewstate wherever possible
For further more read these links.
Improve Web Application Performance
ASP.NET Web Site Performance Improvement
Since so many things can affect performance, it's difficult to provide such a list. We may make assumptions about your code that aren't correct, and may focus on the wrong areas while you suffer poor performance from something we would otherwise take for granted.
Having said that, in general you might keep an eye on:
Don't over-use ViewState. (I'd argue not to use it at all, but that's another issue entirely.)
Keep page resources small (minified text, good image encoding, etc.).
Ensure page resources are properly cached once downloaded.
Try to move most UX logic client-side. (Avoid post-backs for things you can otherwise do in JavaScript, fetch data asynchronously where possible in small chunks, etc.)
The list can go on and on, and that's just with the web tier of the application. You could easily encounter site performance problems resulting from slow server-side code or server-side resource dependencies (database, etc.) that can't be debugged in the browser.
So the main point is to learn your debugging tools. Through combinations of browser tools (FireBug, Chrome Developer tools, etc.), Visual Studio debugging (or whatever else you may use for your .NET code), good logging, and even profiling tools you can identify your bottlenecks and tweak your system accordingly.
Check your website in google page speed :click
It will give your problem . for unwanted style.images and etc.......
If you care so much for speed, stability and scalability you might first question whether ASP itself is a good compromise
when it comes to performance of the web application we need to consider many things this article will help you understand what performance is where to start.
In web application 80 percent of the time it is front end which requires performance optimization, what needed to be optimized is a big question and really hard to answer
this article i found will help you understand the web performance optimization
Web Performance Optimization
I've done some searching and haven't found a specific answer. Anyhow, I was wondering how most medium sized ASP.NET based websites cache data so that they don't always have to database look ups for the same data on different pages when running on a web farm environment. I'm aware that you can use a sql server cache, but to me, that defeats the whole purpose of the cache. If I want to use a dedicated server to share cache (and even possible session data), what do most sites use for this? I've done searching and get a lot of 'guesses' when it comes to implementations, but it's really hard to believe that there isn't some standard way of doing this given that there are so many ASP.NET websites out there.
I am aware of AppFabric that seems like it might do the trick, but only runs on Windows server 2008+ and we're currently using 2003. Also, I've checked out NCache but it seems to be a little pricey.
Has anyone implemented a solution that worked for them? Database lookups can be quite painfully slow when 1000+ users are hitting your site simultaneously.
Thanks in advance!
Might want to take a look at HttpContext.Cache and HttpRuntime.Cache
You can get your information from the database then create datasets (or dictionaries, or whatever you want) and then store those in cache to be referenced site wide.
You can even specify how long you want the cache to persist. And when it expires the next request for that data will go to the database and recreate your cache.
There are certain tables that get called often but updated rarely. One of these tables is Departments. So to save DB trips, I think it is ok to cache this table taking into consideration that the table has very small size. However, once you cached it an issue of keeping the table data fresh occurs. So what is the best way to determine that the table is dirty and therefore requires a reload and how that code should be invoked. I look for solution that will be scalable. So updating the cache on single right after inserting will not resolve the issue. If one machine inserted the record all other on the farm should get notified to reload the cache. I was thinking for calling corresponding web service from T-SQL but don't really like the idea of consuming recourses on sql server. So what are the best practices to resolve this type of problems.
Thanks in advance
Eddy
There are some great distributed caching frameworks out there. Have a look at NCache and Velocity. NCache has some great features for keeping the cached data in sync between different cache nodes as well as the underlying database. But it comes at a price.
Have you tried using sql dependencies or cache dependencies? The library will pole the database every so often to see if the data has changed. An alternative is to use cache dependencies too. You can have a master cache object and have child caches depend on it. so if the master cache change the child caches will be updated.
Edit:
If the above is not a solution you can easily use memcached.net -- wikipedia. Geared toward large sites but it is a solution for your problem.
Here is an article that describes the thinking around setting up a cache.
http://www.javaworld.com/javaworld/jw-07-2001/jw-0720-cache.html?page=1
Generally speaking objects in a cache have lifetimes and when the lifetime expires they are re-fetched from the database. If the data is not so important this eventual consistency allows for a mixture of performance and accuracy of presented information.
Other cache tools add in additional techniques to keep data more accurate i.e. if a particular object is known to be updated then repopulate after the update command is executed.
Im getting to where i need to consider caching for my web application. Im a bit courious as to how long time i should cache the items, so i would like to make some sorts of statistics on how often i use my cache vs how often i load data from my server. How to go about doing this? Should i do this manually with data caching, like this:
Does the data exist in my cache
No - load it into cache and return it
Insert a row into my database for statistics
Yes - use the data from the cache
Insert a row into my database for statistics
To me it seems a bit odd to query the cache and then insert into my database, seems the performance gain is lost then - right?
What to do then?
Instead of looking at this problem as a sitewide problem, I would investigate those areas that are bottlenecks in your system, and consider caching those. The time you cache will depend on the data, and how frequently it changes.
Asp.net has some built in performance tools that will show you quite a bit of information about your cache
http://msdn.microsoft.com/en-us/library/ms972959.aspx
Don't focus on the cache hits vs. misses. Start off by focusing on the data that is retrieved often, but changes very little.
This article has some good information on implementing a caching policy
http://www.c-sharpcorner.com/UploadFile/vishnuprasad2005/ImplementingCachinginASP.NET11302005072210AM/ImplementingCachinginASP.NET.aspx
I would agree with Aaron. Why do you want to introduce caching? What problem are you trying to resolve? Are you having performance problems and are they directly related to database reads?
I have implemented ASP.Net/SQL caching on numerous projects and have found that the bottlenecks usually lie elsewhere i.e. page size.
I hope this helps.
B
I have some ASP.NET MVC actions that generate images dynamically (although it could equally be an ASPX page).
I'm using [OutputCache] to cache these images. I'm just wondering if I need to worry about ASP.NET caching images in memory and taking up too many resources. These are product images of varying sizes for a shopping cart containing only a couple dozen products.
Will OutputCache use disk or just in memory? How intelligent is it? Or should I just save the images to disk myself and implement my own caching system (which is actually the current implementation) ?
For all intents and purposes, I believe that the output cache is completely in-memory - meaning that if the app pool is recycled, the image will need to be generated again.
I've had to do something similar in the past, and I actually implemented a two-tiered system that used the HTTP cache primarily, and used the filesystem as a fallback. If something didn't exist, I generated the image and saved it to disk AND put it in the cache. That way if it gets pushed out of the cache or the app pool recycles, I only have to load it off the disk (it appears you've done the same).
As far as "too much memory", if you explicitly use HttpContext.Cache instead of [OutputCache], you can control the priority of the item in the cache. You can then tweak the settings on your app pool to control how much memory it uses overall, but I'm not sure there's a whole lot to be done other than that. A couple images * 12 products doesn't seem like it would take up a whole lot of memory to me though.
Without knowing anything else about your application, it sounds to me like you could get away with just using the outputcache. However, if you need something more robust and scalable, I'd use the two-tiered system I described. Though, if you've already got that implemented and working, "if it ain't broke..."