Caching strategy, Output Cache vs Data Cache or both?

Question

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.

Tobolsk

Answer 1

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.

Spoonerism

Check out Kigg (codeplex.com/Kigg) for an example of an ASP.NET MVC app which is a digg clone. if your app is exactly like a digg clone, then I would output cache the story pages and the home page. caching the user information may be necessary depending on how your data structures look. – Spoonerism

Answer 2

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.

Exobiology

Are you using a web farm? If so, does each web server have its own inproc cache independent of other web servers? – Counterproof