Best practices in caching in ASP.Net
Caching in ASP.Net is of the following three types:
This is a form of caching in ASP.Net that stores a copy of your Web page in the memory cache so that subsequent requests for the same Web page can be fetched directly from the cache -- the cached output is sent to the application. This improves the application's performance considerably. The following code snippet shows how you can implement page output caching.
<%@ OutputCache Duration="30" VaryByParam="*" %>
The VaryByParam option helps you to specify the variables in the Http Request that would need a new cache entry. Other possible options include: VaryByHeader and VaryByCustom. You can also specify Location and Duration in the OutputCache directive -- you can use these to specify the location of the cache and also the duration for which the Web page should be cached respectively.
Page fragment caching is a caching strategy in which the Web page is cached partially – only fragments of the Web page are cached, not the entire Web page. You can use the same syntax as page output caching. However, you need to apply the OutputCache attribute to a user control instead of the Web page. Fragment caching is helpful when you would need to cache only portions of your Web page -- typically in situations where your Web page contains a mix of common and dynamic sections. As an example, you can have a Web page that contains a mix of menu items and also certain dynamic sections that need to be populated and updated from the database often.
ASP.Net exposes the Cache API for you to store data in the cache for retrieval later. The syntax for storing data in the Cache using the Cache API is given below.
Cache["key"] = "value";
You can also use the Add or the Insert methods. To remote an entry from the cache, you can use the Remove() method of the Cache class. The Insert() method of the Cache class enables you to specify cache dependency. Cache dependency is a strategy that ensures that when the data in the data store (from which the cache has been populated) changes, the cache would then be re-populated immediately. When data in the data store changes, the cache would expire, resulting in a re-populating of the cache with the latest data. You can read more on this from this MSDN article.
You should cache as often as you can and cache data properly in every layer of your application. When using data caching, you should implement a proper strategy to ensure that data in the cache is in sync with that in the data store. You can take advantage of distributed cache managers like Memcached so that your caching strategy can also scale well and provide considerable performance gains -- you can use Memcached to store large data. You should ensure that you cache relatively stale data only -- there isn't any point in caching data that would change often over time. Also, data that is unlikely to be reused should not be stored in the cache. You shouldn't over-use SqlDependency or SqlCacheDependency.
And now, let's know the downsides of caching too. The cache object is available to the current application domain only. So, if you would like to store data in the cache and make it accessible across a web farm, that isn't a possibility. You would have to leverage distributed cache like Windows Server AppFabric Caching or other distributed caching frameworks to have the data in the cache globally accessible in a Web farm.
Caching is a powerful mechanism to boost the application's performance by storing relatively stale data in the memory so that the same can be retrieved from the cache memory at a later point of time. I'll discuss more on this topic with real life code examples in my future posts here.