ASP.NET Cache Limitations

ASP.NET provides a Cache class within the Application scope to let you cache frequently used application data and reduce expensive trips to the database. However, ASP.NET Cache is an in-process and stand-alone cache and therefore has many limitations and problems.

ASP.NET Cache Deployment Limitations:
Since ASP.NET Cache is always in-process, it creates many limitations and problems. None of these problems occur if you use NCache in your ASP.NET application. Here is a list of problems and limitations.

• Data Integrity Problem in Web : A web garden is configured on a web server by specifying multiple worker processes for an application pool. However, in this situation, ASP.NET creates multiple isolated instances of the Cache class, one for each worker process. And, the Cache in each worker process is not synchronized with other worker processes thereby creating data integrity problem.
• Data Loss with Worker Process Recycling: ASP.NET always runs in worker processes and these worker processes recycle by default. Once a process recycles, the entire Cache is lost because it was within this process. This can lead to serious problems if you don't have a backup storage of the cached data. At the minimum, it is a performance issue because you now have to reload the entire cache.
• Cache Size Limitation: An in-process Cache is limited by how much a single process can store. Most ASP.NET applications these days run on 32-bit platforms and therefore there is a 2GB or 3GB memory size limit which has to be shared between the Cache and your ASP.NET application. Although on a 64-bit platform this limit goes away, process recycling becomes an even more serious performance issue since the cache is now much larger and has to be reloaded at runtime.
• Single Point of Failure: The entire Cache is stored on a single server and therefore is lost if this server goes down for any reason.
• Data Integrity Problem in Web Farms: A web farm consists of multiple web servers connected together through a load balancer. The load balancer routes user requests to all web servers thereby distributing the load evenly. In a web farm configuration, each web server creates its own isolated copies of ASP.NET Cache that is not synchronized with other web servers. This creates data integrity problems.
• Scalability Problem in Web Farms: The ideal way to distribute load evenly in a web farm is for the load balancer to send each request to the most appropriate web server based on the load on all web servers. However, since ASP.NET Cache is stand-alone and in-process, the load balancer has to send the request to the same web server where the user was originally serviced. This severely limits scalability because you end up with situations where some of the servers are extremely overloaded and slow while others are free and adding more servers doesn't increase the total processing throughput.

ASP.NET Cache SqlCacheDependency Limitations:
ASP.NET allows you to use the SqlCacheDependency class to create a cache item dependency on a table or row in a database. When a change occurs in that table or specific row, the item in the cache that has this dependency is invalidated and removed from the cache. With SQL Server 2000, you can only create a table level dependency but SQL Server 2005 allows you to also create a row level dependency.
Although, SqlCacheDependency tries to address the severe scalability limitations in ASP.NET Cache mentioned above, it is unable to completely resolve these problems. Here are the problems associated with SqlCacheDependency:

• Performance Issue: The whole idea behind the cache is to reduce expensive database trips. However, SqlCacheDependency is stored in the database and therefore causes major performance degradation. Every time your ASP.NET application adds, updates, or removes anything from the cache, the same information is updated once in the application database and secondly in the SqlCacheDependency database. It is then propagated from the databases to all the other Cache instances, whether in a web garden or in a web farm configuration. This makes cache updates extremely slow.
• Scalability Issue: Database server is not able to scale out as your server farm grows. You may be able to build an active-active cluster of your database but even this cannot grow beyond 2-3 database servers without giving major performance degradation. In addition, this type of a configuration is extremely expensive. Hence, as your server farm grows, if you're using SqlCacheDependency, you'll see a major drop in performance.