Pros/Cons of different ASP.NET Caching Options

I recently asked a question about caching application data in an ASP.NET MVC WebAPI application and it led me to a new question. What are the pros/cons of different caching methods available in ASP.NET?

I have come upon:

• Memory Cache

  http://msdn.microsoft.com/en-us/library/system.runtime.caching.memorycache.aspx

• Using Static Member Variables:

  private static Northwind.SuppliersDataTable suppliers = null;
  

• Application State:

   HttpContext.Current.Application["key"] ="Value"
  

• Data Cache:

  HttpRuntime.Cache.Insert(
    /* key */                "key", 
    /* value */              "value", 
    /* dependencies */       null, 
    /* absoluteExpiration */ Cache.NoAbsoluteExpiration, 
    /* slidingExpiration */  Cache.NoSlidingExpiration, 
    /* priority */           CacheItemPriority.NotRemovable, 
    /* onRemoveCallback */   null);
  

I am sure there are others, and I know they all technically store the data in memory...so any idea what I should use for an ASP.NET MVC webapi?

My Previous Question: Caching application data in memory: MVC Web API

Each Caching technology/methods have their own set of features. These features may seem to be of disadvantage in one application requirements but can be advantageous in other application requirements.

So, in short , depending on your requirements decide which Caching technology and what features are best for you.

For example, Let us discuss some client side Caching techniques.

MSDN says that we can also use HiddenField to store only small amounts of frequently changing data in hidden fields because this data is included in the roundtrips to the server on every postback.

Advantage of this feature: Reduces the workload on your server by storing page information using client-side options.

However, MSDN says clearly that : This approach has minimal security support.

Thus, one may or may not use this feature always as security considerations are also there.

Consider one more example, Page Output caching : it is of 2 types, page output caching and page fragment caching.

Page output caching caches an entire Web page and is suitable only when the content of that page is fairly static. If parts of the page are changing, you can wrap the static sections as user controls and cache the user controls using page fragment caching.

And one last comment on Application vs HttpRuntime.cache:

Application is not a cache, its a global named value collection. if you add an object to Application it will stay until a an appdomain recycle.

• Application variables are shared variables among all users of a web application
• Application variables behave like static variables and they are substitute of static variables as static variables are stateless in web applications
• Only shared values should be persisted in Application variables, and as soon as they are not in use they should be removed explicitly.

Cache :It is possible to obtain significant performance improvements in ASP.NET applications by caching frequently requested objects and data in either the Application or Cache classes. While the Cache class certainly offers far more flexibility and control, it only appears to offer a marginal advantage in terms of increased throughput over the Application class for caching. It would be very difficult to develop a testing scheme that could accurately measure the potential advantages of the Cache class's built - in management of lesser-used objects through the scavenging process as opposed to the fact that Application does not offer this feature. The developer needs to take decision in this case and should be based on the needs and convenience of the project and its usage patterns. Check this link for more.

Refer this MSDN article for a complete great explanation on all Caching technologies in Asp.net with discusiion on the features of each technology.

Also, these 2 links are a great source to start with:

• http://weblogs.asp.net/pjohnson/httpruntime-cache-vs-httpcontext-current-cache
• http://devshop.wordpress.com/2008/04/10/how-to-choose-from-viewstate-sessionstate-cookies-and-cache/

Regarding MemoryCache vs ASP.NET Cache: they provide very similar functionality. In an ASP.NET 4 application, I'd generally prefer the ASP.NET Cache, if for no other reason, then because of a bug in .NET 4, which is apparently fixed in .NET 4.5.

Static fields are appropriate to store shared data that does not need an expiration policy.

Application state isn't much more than a static dictionary with locking semantics that is compatible with classic ASP - I'd only use it for backwards compatibility with legacy classic ASP code.

When using Web API your first choice for caching should always be to set the caching headers in the HTTP response. HttpResponseMessage.CacheControlHeader.

Your last options should be anything that depends on HttpContext or HttpRuntime, as that will tie you to particular hosts. Web API applications should be built independent of their host.