.Net Cache API vs Application State
So, you’ve got some data in your application that you need to make available to any future request, but you don’t want to fetch or create it every time. This data is not large, changes rarely and is accessed often.
Do you use the .Net Cache API, or the Application State to store this data?
So what”s the difference?
The .Net Cache API is much more flexible than the Application State, but the most important part to understand is that it is volatile storage. This means that there is no guarantee your cached object is going to be there when you next request it. The .Net Runtime may well decide to destroy your cached object to free up memory, or after some explicitly set condition is met such as a caching duration (after which the cache object is destroyed).
The Application State allows you to store objects that will be available for the duration of the applications life, unless you explicitly remove them.
So which is it?
I always use the Application State to store data I wish to be available for the lifetime of the application. I see no reason to use the .Net Cache API simply because I cannot guarantee its behaviour.
If on each (or most) requests you need to use this data, then the most efficient way to write your application is to have it maintain the data indefinitely once it has been created. You are not saving on server resources by having an item removed from memory only to be recreated and added straight back in. You could argue the contrary as the effort to recreate the data will itself use more server resources. (If you are using a shared server then there are considerations here as other sites may have good use for the free memory in between requests.)
What about using caching with ”CacheItemPriority.NotRemovable”?
Great in theory, however I have had issues in the past with busy sites crashing because an object I assume cached suddenly isn’t. I cannot fully explain what happens here, and I always test the cache object exists before initially accessing it, but the problems are with a cached object suddenly becoming ”bad” mid-code block. The most common occurrence of this is when enumerating through a cached collection object.
Even though it should work the same, and if we assume for the sake of argument it works perfectly, there is still no reason to cache an object indefinitely when you can instead store it in the Application State and be confident it will remain there.
So when do you use the .Net Cache API?
Common sense tells you that you can”t possibly store everything you want to in the Application State without using a tremendous amount of memory. This is when caching comes into its own. You can throw a number of objects into cache and .Net Runtime will ensure only the least important objects are removed if more memory is needed. It is extremely easy to use, being no more complex to use than accessing a session variable.
A typical application of mine will contain a combination of both Application State and .Net Cache API. The Application State is used to store small frequently accessed data, and data which would noticeably degrade performance if it was recreated too often. The .Net Cache API is used for everything else, but typically datarows returned from sql tables.
Using the .Net Cache API with commercial shared hosting.
I wish to end this article with an observation of mine when trying to use the .Net Cache API on shared IIS servers. Simply put, it doesn’t work. The Cached objects are cleared out so fast they are unlikely to be there before the next request comes in. I don”t know why this should be the case, possibly too many sites are using the ”CacheItemPriority.NotRemovable” selfishly leaving no space for any other sites, or perhaps simpler still there is too little memory to go around. I have yet to find a shared hosting service where this does not happen, but on dedicated servers the .Net Cache API behaves as it you would expect it to. Please bare this in mind when developing applications destined for a shared server.