Pros / cons of various ASP.NET caching settings

Question

I recently asked a question about caching application data in an ASP.NET MVC WebAPI application, and this led me to a new question. What are the advantages / disadvantages of the various caching methods available in ASP.NET?

I've come:

• 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 Status:

    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 that they all technically store data in memory ... so any idea what I should use for ASP.NET MVC webapi?

My previous question: Caching application data in memory: MVC web API

Answer 1

Each caching technology / method has its own set of functions. These features may seem disadvantageous in one application, but may be useful in other application requirements.

So, in short, depending on your requirements, decide which caching technology and which 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 that data is included in server callbacks for each postback.

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

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

Therefore, you can or cannot use this feature always, since there are security concerns.

Consider one more example , Page Output caching : these are 2 types, page output caching and page fragment caching.

Page output caching caches the entire web page and is suitable only when the contents of this page are quite static. If parts of the page change, you can wrap the static sections as user controls and cache user controls using cached page fragments.

And one last comment on Application vs HttpRuntime.cache :

Application not a cache, its global collection of value values. if you add an object to Application , it will remain until the approximation is restored.

• Application variables are common variables among all users of a web application.
• Application variables behave like static variables, and they replace static variables because static variables have no state in web applications.
• Only general values ​​should be stored in application variables, and as soon as they are not used, they should be explicitly deleted.

Cache : You can achieve significant performance improvements in ASP.NET applications by caching frequently requested objects and data in the Application or Cache classes. Although the Cache class certainly provides much more flexibility and control, it seems to offer the ultimate advantage in terms of increased throughput over the Caching Application class. It would be very difficult to develop a testing scheme that could accurately measure the potential benefits of the Cache class of in-line management of less-used objects through the cleanup process, rather than the fact that the application does not offer this feature. The developer must make a decision in this case and must be based on the needs and convenience of the project and its patterns of use. Check out this link for more details.

See this MSDN article for a complete explanation of all caching technologies in Asp.net, with a discussion of the features of each technology.

In addition, 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/

Answer 2

Regarding MemoryCache vs ASP.NET Cache: they provide very similar functionality. In an ASP.NET 4 application, I usually prefer the ASP.NET cache, if not for any other reason, and then because of a bug in .NET 4 , which seems to be fixed in .NET 4.5.

Static fields are suitable for storing general data that does not require an expiration policy.

The state of the application is not much more than a static dictionary with blocking semantics compatible with classic ASP - I would use it only for backward compatibility with old classic ASP code.

Answer 3

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

Your last parameters should be any, depending on HttpContext or HttpRuntime , as this will connect you to specific hosts. Web API applications must be built regardless of their host.