Welcome readers!
As stated in my last post, I will highlight the various ASP.NET Cache limitations that make it a less than ideal choice for employment in case of web farms.
Let’s try and hack out an intro for ASP.NET Cache in light of what we learned in the last post. The words highlighted in blue have been explained in my previous piece(s).
ASP .NET Cache Intro:
ASP .NET cache is a standalone in-proc cache for a single web server. In case of web gardens, it creates separate cache instances, one for each worker process. These cache instances work independently and have no synchronization with each other. When your web farm grows, SQL server and SQL dependencies are employed to keep data synchronized across multiple servers.
Problems with ASP .NET cache
1. The Web Garden Configuration (standalone in-proc cache means data redundancy and low availability):
The Web Garden situation and the problem it generates due to ASP.NET’s in-proc behavior have been described in my previous post. To reiterate, a Web Garden, in the case of ASP.NET, means multiple independent worker processes having individual instances of cache. If any worker process fails, its cache instance is lost. And, since these cache instances are disjoint, this gives rise to data redundancy and hence data integrity issues.
As shown in the diagram above, in a web garden configuration each worker process has its own copy of the same cache.
· As explained above, there is no synchronization between various worker processes due to which all ASP.NET caches work independently. This gives birth to problems of data duplication and hence data integrity.
· Usually worker processes recycle, and as a result wipe out the entire cache which means that ASP.NET caching is not a reliable way of storing data. If adequate backup facility is not provided, this could be a very serious issue for high end applications due to loss of valuable data. Another drawback is that the cache has to be loaded again in its entirety.
· When you have an in-process cache, you are sharing your application’s process memory with cache memory, meaning you are always compromising on your caching ability depending on how much memory your application requires.
· This is also a single point of failure since the entire application can come to a grinding halt if this server holding unsynchronized in-proc cache goes down.
· It also means that if you need some downtime for maintenance reasons that is going to be extremely difficult to achieve.
These ASP .NET cache drawbacks would be a setback for any major developmental effort making it impracticable to incorporate it into a high performance, mission critical application.
2. Does not support direct cache synchronization in web farms
(No synchronization between caches directly)
As previously listed, a Web Farm is a collection of servers that are connected together using a load balancer.
· Once again due to its in-process nature ASP .NET cache simply does not recognize multiple servers and the various cache instances that reside on them. Due to this, these caches across different servers remain secluded and unsynchronized resulting in data redundancy and integrity problems.
· The load balancing mechanism in a web farm is also severely hampered using a stand-alone in-process cache. The load balancer has to send a recurring user request back to the original server where it was serviced for the first time. This creates an unbalanced approach resulting in load being accumulated on certain servers rather than all the servers in a web farm sharing it evenly.
· Due to the unjust load balancing mentioned above, scalability suffers tremendously. Adding more serves does not make any sense in this situation as it might aggravate the problem. Hence, more users cannot be entertained by the system.
3. Performance and scalability issues with SQL dependency (SQL Dependency makes your app slow, and non scalable)
Once they started to go into multi-server environments, Microsoft developed the SQL cache dependency feature that gave the ability of synchronizing ASP.NET cache across multiple web servers through the database. For lower end applications with a couple of web servers it was great, since they could afford to go to the database and fetch data. However, for high performance applications, in addition to dragging performance down, this solution is also non-scalable.
· Since SQLCacheDependency resides in the database, it defeats the very purpose of having an in-memory cache. Any update process has to be performed at the database, then the SQLCacheDependency database as well as copied over to all the other cache instances in the web farm. The whole process is painfully slow.
· The more servers you add to the web farm, the slower the performance of your application due to the frequent DB I/O operations.
· SQL dependency relies on event based notifications. For high transaction applications, they tend to get quite chatty generating high volumes of traffic. This would result in creating network noise and you would see a performance drop.
· The real time nature of events could also cause application’s performance to drop significantly as they start queuing up in high transaction environments.
· One of the biggest drawbacks or limitations that this puts on the application is that if you decide to increase the number of servers in your web farm due to increased load, you just can’t simply start adding more database servers to the configuration to compensate.
In conclusion, ASP.NET Cache is not a scalable solution for more than 2 servers. Its importance however cannot be denied when it comes to smaller configurations, but as far as high transaction multi-server web farms are concerned, one must start looking into other options. These options will be discussed in detail in the Fixes section of this web log.
Don’t lose contact, you’ll soon find out how to counter all the various limitations, drawbacks and bottlenecks of ASP.NET Cache discussed in this article. In the meantime, you can learn about ASP.NET Cache fixes at www.alachisoft.com
Hope to catch you reading at the next post!
