Saturday, September 11, 2010

Windows Server AppFabric Caching Framework


Windows Server AppFabric Caching, also called as Velocity is a framework for providing a unified Cache. Application Caching is nothing new and has been around for many years. It definitely saves those milliseconds or even more depending on the number of concurrent users fetching the data.

Earlier Cache used to be part of the Web Servers. Later, they moved into the Application Servers. However, the capabilities of the caching depended on the capacity of the Application server. With more and more concurrent users, it became important to have a much bigger caching servers. In order to prevent any bottlenecks on these servers, there was a need for a Caching framework which could provide all the capabilities of a load balanced Web Servers.




The following are some of the functionalities that was expected and delivered from the Velocity framework:
  • Load Balance of the Cache Servers
  • Provision to scale dynamically without having to stop the applications
  • High availability in case some Cache Servers goes down
  • Maintaining consistency in data copies stored across Cache Servers
  • Provide a mechanism to invalidate the Cache when the actual data store gets changed

To Install & Configure the framework follow the link http://msdn.microsoft.com/en-us/library/ff383731.aspx 

There are two places of storing the configuration.
  • Network Shared folder - Usually smaller applications (1-5 Servers)
  • SQL Server - For larger Enterprises (greater than 5 Servers)
Configuration can be done either Programmatically or by using the Windows PowerShell. The AppFabric/Velocity framework related commandlets will be installed as part of the framework.

The following are some of the terminologies that are used in Velocity Framework
  • Cache Server
  • Cache Host - Windows Service
  • Cache Client - Web Application Accessing the Cache 
  • Local Cache - Data is stored in memory of the Web Application
  • Server Cache - Data is serialized and saved in servers other than Web Application Server
  • Lead Host - Responsible for storing Cache and also to co-ordinate with other Hosts for managing the integrity of the other Cache Servers. 
  • Cache Cluster - A set of Cache hosts working together to provide a unified Cache view

There are two ways of partitioning a Cache. You could configure data to go into one of these partitions to effectively manage the cache for performance and also to isolate the invalidating effect on other cache data.
  1. Named Cache
  2. Named Region


Memory management
There are two ways of invalidating the Cache.
  • Timeout
  • Notification (Default polling interval of 300 secs) - Will check for any notifications programmatically.

Periodically, invalidated cache gets cleaned up for effective Memory management. However, there may be cases where the framework may choose to remove cache data when there is a crunch for memory. You application may get exceptions when they are programmed by completely expecting the data to be in cache. Hence it is a must to write your applications for such events.

The eviction strategy used by Velocity framework is LRU (Least recently) used. i.e. Old data gets destroyed first.

High availability is achieved by making copies of the Cache data. The number of copies that needs to be maintained can be configured.

  
Security
Security is done at Transport level. Velocity framework can be configured to allow only certain user-context to access the cache servers. You should allow the user context of the Web Application - Application Pool to have access to the Cache servers. 

Lastly, ASP.net 4.0 applications can leverage on the Velocity framework for storing the Session states.
Hopefully, I have touched some concepts of the new caching framework. Can't wait to implement this on my next project.
References:
http://msdn.microsoft.com/en-us/library/ee790954.aspx

No comments:

Post a Comment