In this post, Sanjog Sharma, Software Developer at Miles Technologies, discusses the strengths and weakness of two major caching solutions for ASP.NET Web Applications.
Caching is one of the solutions a developer thinks of when it comes to improving performance of slower sites. Caching can help reduce the amount of database calls by allowing an intermediate storage closer to the consuming application (usually in-memory) where frequently accessed data can be kept. When an application requests for some data, instead of making trip to database, it can be accessed directly from the cache. This reduces load on database and allows faster data access.
This post will address a couple different solutions available for ASP.NET Web Applications.
This caching technique provides functionality to store data objects and provides us with methods that allow adding/removing data from the cache. It also provides features like configuring cache item expiration, priority, dependency, etc.
ASP.NET Cache is an InProc cache, which means the cache resides within the process. By its nature of residing within a process, the items cached by one process cannot be accessed by another. If an application is deployed in web garden configuration in IIS where there are more than one worker processes, the data cached by ‘Worker process 1’ is not accessible from ‘Worker process 2’ since each of these processes has their own cache object. Since the cache has to reside in the process, the size of cache depends on worker process memory limit. Also, the cached data is lost every time the process recycles.
AppFabric Cache is an in-memory, distributed caching solution which stores objects on a cache cluster. A cache cluster may consist of one or more on-premises server and AppFabric provides API for use with .Net applications to read/write data on the cache cluster.
Since it is out-of-process, the cache can be shared by multiple worker processes and even multiple applications across multiple servers. Also, cached data will not be lost when the application pool recycles. If there are multiple portals that need to share same cached data or there is a requirement to manage the cached data from a different application, this is possible by configuring all the applications to point to the same cache in the cluster. While the cache cluster may have data stored on multiple servers’ memory, the application consuming the data just sees it as one unified resource. AppFabric caching has following other features:
- Scalability: The distributed nature of the cache allows us to increase the cluster’s memory by adding new server (also called cache host) as the application requirements grow.
- High Availability: When enabled, a backup copy of cache is stored on a second server, so if the cache server goes down, the backup cache serves the requirement.
- Named Cache: Applications store data in named cache and AppFabric allows configuration of multiple named cache which are independent from other. This allows multiple applications to use the same cache cluster.
- Regions/Tags: Users can create a logical space called Region where data can be cached and tagged as well. Items can be searched by tag. However a Region can only reside within a single server, so we will not benefit with the distributed nature when using it.
- Local Cache: We can configure our application to use local cache so it does not need to make frequent trips to a cache server in order to fetch data. Items stored in local cache can be invalidated based on specified interval of time or notification from a cache cluster.
Much like any other method, AppFabric caching is not with out its weaknesses. Some of its drawbacks include:
- Additional hardware is needed for setting up cache cluster.
- Cache cluster configuration needs to be stored in a SQL Server database or a XML file located in a shared network drive. If the connection to that configuration store is lost, then the caching would stop functioning.
- There is no cache dependency feature available out of the box.
If an application is hosted in a single server environment and is not going to have any scaling requirements then ASP.NET cache serves the purpose. If we are looking for something that can be shared across web garden/farm, then ASP.NET caching cannot fulfill this requirement and we need to look for out-of-process caching. AppFabric caching fulfills the requirement in such a scenario. Also, AppFabric caching is a perfect solution for scenarios where cache needs to be shared between multiple applications like front-end portal and back-end admin site.
Have any questions or comments about this post. Do you agree with our conclusions? Let us know in the comments section below!
Want to learn more about how custom software solutions can help your business run more efficiently? Contact us today to speak to a software expert.