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!

Before we immerse ourselves into thoughts of ASP.NET Cache limitations, let’s explain worker processes, web gardens and web farms in a little more detail so that we can understand the issues of synchronization, speed, reliability and scalability in the context of caching. Doing so would not only help us realize the drawbacks that ASP.NET Cache entails but it will also make it possible for us to outline the situations in which one should contemplate using it or looking for alternative solutions.

Worker Process:

Worker processes help separate various applications running on one server. If one worker process fails or collapses, it does not affect the other applications that are running in separate worker processes. This makes the server environment stable without any drop in an application’s performance due to process separation.

Similarly, a single application can run in multiple worker processes that are all independent of each other. This provides reliability for the application in case one worker process gets corrupted. However, each worker process now contains its own instance of the Cache and you end up with multiple copies of the same cache on the same web server.

Additionally, worker processes do recycle by default although you can configure them not to. Once they recycle, any data in the process is lost. And, Cache housed inside of such processes is no different. This causes major issues which will be discussed in the next post in this category.

Web Gardens:

A Web Garden configuration means an application running in more than one worker process on a server. Having multiple worker processes provides reliability because if any one worker process gets corrupted, another one is available to service user requests. Multiple worker processes also provides more memory to the application because each worker process has its own memory.

In the context of InProc (in process) caching – one that ASP.NET Cache provides – this has some peculiar issues. Each worker process has its own copy of the Cache. And, while this might allow more Cache storage space, it also creates a cache synchronization problem across worker processes. This can cause some data integrity issues if two caches are out of sync.

Web Farms:

A Web farm can be described as multiple servers hosting a single application and sharing the user request load. When your online users grow, you need to add more servers to process the various user requests that pour in. These servers share the load through a common load balancer than distributes these requests on an even basis among these servers.

In such a situation the need for caching is even more accented. As the number of users increases, so does the load on your application. For example, the number of sessions would go up significantly on each of your web servers. The data that needs to be created by your application is also compounded. The network trips needed to access the database are multiplied and the I/O operations increase rapidly. If you do not handle this load properly, due to all the above mentioned overheads, the performance of your application could be severely hampered. It might respond slowly, prompting your users to lose interest and resulting in loss of revenue for the service provider.

These are just the circumstances around which ASP.NET operates. Once we consider ASP.NET Cache for Web farms, we start to know that its bottlenecks far outweigh the performance overheads discussed above, especially in the case of Web Farms.

A caching solution should have the ability to properly address the above mentioned bottlenecks and configuration drawbacks. It should not only provide a performance enhancement – which ASP.NET does – but also be able to make an application more scalable so it can handle more users and session data. It should also be able to make an application perform reliably and efficiently.

Now, exactly how does ASP.NET Cache fare in light of the various requirements, bottlenecks and restrictions highlighted in this post! Read the next post to find out. If you need immediate information try visiting  www.alachisoft.com