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!

Dear readers,

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

Hi readers,

The previous post involved an overview of ASP.NET Cache with special emphasis on the types of caching available and the main operations that can be performed on the cache. In today’s post we’ll be discussing some important features related to the ASP.NET Caching mechanism and their significance.

But first, I wanted to focus on the in-process (InProc) nature of ASP.NET Cache as this is a prominent characteristic. As discussed in the previous post, the Cache instance is created within the Application scope and resides within the application’s worker process memory. This results in extremely fast Cache access since data does not have to travel across process boundaries or across the network to access the database. Additionally, no serialization and deserialization cost is incurred by the application. For stand-alone single server environments, this is God-send.

As specified in the previous post, data items are not supposed to be kept in the cache indefinitely. They are only temporarily stored there due to many reasons as explained below:

• The available memory for the Cache is limited to the memory size of the application processes. Therefore, if memory starts getting scant, the Cache starts throwing items out – based on a priority that was set initially or if the items have not been used recently – to compensate for the loss of memory. This is called scavenging.

• New items have to be brought in because they are needed by the application.

• Data in the Cache can also get out of sync with the database where another application or user might update it. Therefore, in most situations, applications choose to keep data in the cache for a limited period of time. And, after this time is up, the data is automatically removed from Cache. This is called expirations.

• Cached data might be related to other data either inside the cache or a file in the file system. This relationship is captured by the ASP.NET Cache through (dependencies). This allows a cached item to be removed from the cache automatically if whatever it was depending on is updated or removed.

• Keeping the above requirements in view, the ASP.NET Cache class also has features that make it possible for you to determine the way data items are cached and the amount of time they would remain there.

Scavenging:

When you have an in-proc cache and you do not want it to be too much of a burden on your memory resources, you have to be able to proactively look for items that you can retire or take out of the cache. At the time of insertion, ASP.NET allows you to specify the priority of an item as high or low by using the CacheItemPriority object. When the memory becomes low due to too much items being added (or some other reason), the items with low priority can be removed from cache.

Expirations:

In the same manner, items in the Cache become “stale” meaning they may become out of sync with the database because somebody else changed the corresponding data in the database. So, you specify an expiration period after which the cached item is automatically removed from the cache. ASP.NET Cache offers you two options when it comes to expirations:

2.1 Fixed time:

At the time of its addition, a certain item can be pre-determined to stay inside cache for a fixed amount of time. It is automatically ousted from cache when that time is up. The fixed time for example can be set to 5 minutes and after that a data item, no matter how many times it has been accessed in the past, whether recently or a long time ago, is forcibly taken out.

2.2 Sliding time (Idle time):

If a data item that resides inside cache sits idle for a certain amount of time, it can be retired from cache using this option. It basically means that the mechanism has to wait for a specified amount of time after a data item was last accessed and withdraw it from Cache. The most common analogy that can be given is that of a session which expires after a set amount of time if no activity takes place.

Notification of Item Removal From Cache:

This neat feature allows you to be notified in case a data item is removed from cache that besides being frequently accessed takes a lot of computing to be created. Once your application knows that it has been removed, it can take an appropriate action including reloading it from the database and adding it back into the cache.

Dependencies:

There are certain instances where you want an item in cache to be removed if another related cached item, a file, or a database record was updated or removed. This is done to ensure that the cached item is always correct. ASP.NET provides various dependencies that help you achieve this by removing the cache item whenever a corresponding cached item, a file, or a row in the database changes. Since most data is relational, you can easily maintain data integrity in this manner.

The various types of dependencies are discussed below:

4.1 SQL dependency:

ASP.NET contains a SqlCacheDependency class that helps you set up a data item inside cache to be dependent on some database table or row (record). The table could belong to a SQL Server 7, SQL Server 2000, or SQL Server 2005 database. However, only SQL Server 2005 has the option of selecting a dependency on a certain row or record. For other databases, you must select an entire table to depend on.

An example of such a dependency is a stock reporting web page having a data item dependent on a database record. Whenever that database record is altered – meaning a field’s value is changed – the cache removes the dependent entry. The next time it is required, it has to be freshly created by loading it from the database again. This besides keeping the cache current also helps to synchronize it with your database (a concept we’ll be discussing in detail in the limitations section). And if the Cache is current, your web application can quickly utilize it to generate the report instead of having to make frequent database trips.

A greater synchronization effort is required when you have a web garden where multiple processors are incorporated into a single server and most importantly in the case of a web farm where your application is running on a number for web servers simultaneously.

It must be mentioned here briefly (as it will be covered in detail in the limitations category of this web log) that in case of web gardens you can only synchronize the various caches with the data store and not among themselves. Similarly, web farms where the need for synchronization and freshness is exponentially enhanced since the application’s scalability, availability and performance heavily depend on it; ASP.NET cache does provide an up-to date cache using the above mentioned dependency but fails to directly synchronize the various caches with each other across the different web servers. As mentioned earlier, this would be covered in great detail in the limitations section of this blog.

4.2 File Dependency:

You can specify a cache item to be dependent on a file. As a result, whenever the file in question is removed or altered, the cache item that depends on it is removed automatically helping to keep the cache current.

4.3 Key Based Dependency:

This is an excellent way of handling relationships among items that are cached. It allows you to mention that one cache item is dependent on another item in the cache. Remember when placing a data item in cache you have to specify a key and give its value. When the original data item is removed from Cache, the data item which depends on its key would also be removed.

For example, you are caching customer objects and order objects that belong to a specific customer. If a certain customer object is removed from cache, all the orders that are associated with it that reside inside the cache would also be removed.

4.4 Other Dependencies:

There are other types of cache dependencies that can be created. ASP.NET also allows you to create Custom Cache Dependencies if such a need arises in your application. You can write code and make a cache item dependent on other elements.

There is also something called an Aggregate Dependency that can be used to make a cached item dependent on severak elements by using the AggregateCacheDependency class. If any of the elements or dependencies is altered, the cached item is removed.

To recap, we have tried to discuss some main features that make ASP.NET Cache an appealing choice for .NET applications that require performance enhancements. We went through the INProc nature of ASP.NET Cache, its various policies like notifications, expirations and dependencies. In my opinion, for single server, standalone applications, ASP.NET Cache is a wonderful addition and goes a bang up job of making it perform faster.

However, my coming posts are going to highlight the various limitations that it has when considered for web gardens or for multi-server environments such as web farms. For a sneak peak of what’s to come please visit www.alachisoft.com

Until next time!!!

What is ASP.NET Cache?

For those who are new to the concept, ASP.NET Cache provides a powerful way of storing frequently accessed data rendering your application remarkably fast.

Normally, when a query is executed, data has to be fetched from the database so as to provide the user the requested information. And, a database trip is usually very expensive in terms of performance. This is because of multiple reasons. First, a network trip is involved to the database server. Second, the database server has to compile and execute an SQL query, perform a database I/O operation and then return the results. This specially becomes more visible when you increase the number of transactions.

In order to offset the above mentioned overheads, ASP.NET framework provides an ingenious way of caching frequently needed data close by with the aim of enhancing an application’s performance. Data is stored inside the memory of the application worker process and is extremely fast as compared to a database trip.

Types of ASP.NET Caching

Now let’s discuss the different types of caching available in ASP.NET. To make it possible for programmers to create high end applications, ASP.NET caching comes in two flavors.

The first type helps cache application data inside memory by using a Cache class in the Application scope. With it, programmers can store frequently accessed data inside server memory to avoid having to fetch it again from the database to reproduce it the next time it is needed. Consequently, the application’s speed is dramatically improved.

The second type called Output Cache provides a way to store the output of an ASP.NET page. This allows you to avoid executing that ASP.NET page the next time a user requests it. Instead, the output generated from the last call is returned. This gives your application a considerable performance boost.

1. ASP.NET Application Cache:

ASP.NET provides a Cache class. The Cache instance is created within an Application scope and ends when the application ends. This behavior is termed as being in-process (or in-proc) since the cache resides within the process space of an application. It does have its advantages (which will be discussed in the future posts under this category) as well as its limitations (which will be discussed under the limitations category of this blog).

Using this Cache class, you can perform Add, Insert, Remove, and Get operations. Add lets you store data (any .NET object) by providing a key for it. Similarly, Get lets you fetch data by specifying a key for it. Cache class also provides an automatic data expiration feature that is very useful. Through expirations, you can remove data after a brief interval. This serves two purposes. One, it keeps the data fresh and consistent with the database. And, second, it frees up memory so you can cache other data items.

You can also synchronize your cache with your database by using SqlCacheDependency. It makes sure that if an item changes in the database, it will automatically be removed from cache, helping to keep your cache accurate to a certain extent (more on this in the coming posts).

2. ASP.NET Output Cache:

Output Cache keeps the output of an ASP.NET page in memory so that the next time a user requests that particular page, the page is not even executed and instead its results from the cache are returned to the user. The result is an extremely fast and efficient response. This would be an ideal scenario for pages that make numerous database trips to fetch data but their results do not change on a frequent basis.

Depending on your needs, you can cache entire pages or just portions of a page. Full caching stores all the contents of a particular page which can be later retrieved upon a user request. Partial page caching works in two ways.

2.1 Control caching

Pieces of a page output can be cached by putting the data in a user control and caching that control rather than the whole page. For example if you have a sports page where you have a running commentary, news items and game scores. You may want to put news and game scores (the final scores) sections into cacheable user controls because they do not change but on a daily basis as compared to running commentary that changes by the minute.

2.2 Post-cache substitution

In this type of Output Caching all the page contents are placed inside the cache. Some are static, meaning that they do not change, while others are dynamic for which output is generated dynamically.

ASP.NET Cache Operations:

As a developer, it is of paramount importance that you be able to manipulate cache in a way that helps boost application performance. The three major operations that you can perform with ASP.NET Cache storage are provided below.

1. Adding a data item to ASP.NET Cache

ASP.NET Cache class allows you to use 2 different methods for adding an item to the cache. The first one is the simple Add method while the second is the Insert method. The difference between them is that the Add method returns the object added and if you accidentally add an item that is already present inside the cache, it will not be replaced and it would not cause an exception to be raised.

The Insert method on the other hand has many overloads in order to set dependencies, expirations and removal notifications (a topic that will be discussed in the next post under this category). If you are using this method to add an item to the cache, remember that it will replace any items that exist in the database with the same name.

The following C# code adds a data item to cache by specifying the key and the respective data item.

Customer cust = LoadCustomerFromDatabase(“1000”);

Cache[“Customer:CustomerId:1000”] = cust;

The following C# code adds a data item to cache by specifying the key and the respective data item.

Customer cust = LoadCustomerFromDatabase(“1000”);

Cache.Insert(“Customer:CustomerId:1000”, cust);

2. Retrieving a data item from ASP.NET Cache:

You use the Get method to retrieve data from the cache. In order for you to retrieve anything from the cache, you must have first put it there yourself as described above.

The following C# code retrieves a data item called Customer from cache. It checks for the availability of that item and if it is not found, it loads it from the database and adds it to the Cache.

Customer cust = (Customer) Cache[“Customer:CustomerId:1000”];

if (cust == null)

{

cust = LoadCustomerFromDatabase(“1000”);

Cache.Insert(““Customer:CustomerId:1000″, cust);

}

Notice I have used the Cache.Insert method for adding a data item above. I could have also used the Cache[] technique. Please note that LoadCustomerFromDatabase() is assumed to be a method in your code that knows how to fetch a Customer from the database.

3. Deleting a data item from ASP.NET Cache:

Data inside ASP.NET cacheis not stored indefinitely, it is meant to be temporary. If you want to remove any cached item, you can do so with Cache.Remove().

ASP.NET Cache also provides automatic data removal through expirations and CacheDependency (we will discuss these in the next post under this category).

The following C# code deletes a data item from cache.

Customer cust = (Customer) Cache.Remove(“Customer:CustomerId:1000”);

Here ends this post that outlines ASP.NET Cache intro, its types and how to perform main operations. In the next post we’ll examine how various important ASP.NET Caching features work. If you need more indepth information please visit www.alachisoft.com

Stay in touch to discover more about ASP.NET Cache!!!