Distributed Cache is generally used to enhance performance and scalability which is essential for any kind of application which demands effective performance even during the peak load; because there is huge differences to fetch data from a CPU register vs. cache vs. RAM vs. disk vs. Network. Generally, the database operations are always costly and database scalability is relatively not as easy as scaling other tiers such as Cache or Application, So it is no brainer to ask a question like, why should we fetch the data again from the disk when we can save the data for some time and reuse it, again it depends upon the nature and volatility of the data.

It doesn’t matter whether it is a consumer or enterprise application, after getting used to social web scale applications such as Facebook, Twitter, Google + , Linked In and numerous others, nowadays every user expects the services to be lightning fast and no one wants to see the “Loading …………..” again and again. During the peak hours when the application is accessed from different parts of the world, if it executes millions of query for each and every request by different users for the same or different data, the response time and the latency will increase tremendously. Especially In a multi tenant environment, the data usage patterns exhibits “Localness”, most of the time users tend to use the same data repeatedly within a short span of time. It becomes inevitable to use caching in such applications to reduce the database latency.

Key Features of Distributed Caching

• Well Seeding and Auto Refresh
• Dynamic Compact Serialization
• Expiration
• Eviction
• Synchronizing of data in Cache with Other Environments
• Lock and Unlock the data

“No better way to speed up the app without using proper caching in a distributed application”.

Retrieve data from Cache Cluster

Caching and celloSaaS

celloSaaS uses Velocity aka Windows Azure App Fabric as the default Cache Provider. App Fabric Cache is a distributed in memory and out of PROC Caching System from Microsoft. It provides a unified view for the application tier to put and get the data with multiple cache nodes on a cache cluster. As soon as data is accessed from the application/database, it will be placed in the cache of the clustered servers temporarily. Cache information will then be replicated to each node of the cache cluster. This means that the cached data will remain in the cloud cache servers based on the expiration policy, and cache will be flushed from the servers to release the memory based on the defined expiration. At any given point of time, the data will be available in the local cache as well other nodes of the cache cluster; the other biggest advantage of APC is that it offers a custom session state provider for the ASP.NET Web application by default.

celloSaaS provides a wrapper class for AppFabric Cache, this provides basic methods to get (), put (), Remove (), refresh () and so on. celloSaaS doesn’t mandate the developers to use AppFabric Cache, Based on the needs and the robustness of the application , the developers can opt for any Cache providers such Amazon AWS ElasticCache, NCache or Custom Built Cache Provider, all you need to do is inherit “ICacheManager” interface and implement those methods as well as update the configurations in the web.config. celloSaaS automatically picks up the configuration and propagates based on the settings.

celloSaaS follows all the best practises when it comes to Caching throughout the framework; it also provides the application user, an explicit Remove All Cache Functionality to completely flush the data from the Cache Cluster. All the base components written in celloSaaS are decorated with [Serializable] attribute which makes the object to be serializable both XML and Binary to store it in cache. Similarly it also uses cache in all the other Non functional components such as Scheduler, Business Rules, Workflows, Reporting Services, Meta Data Management, View Data Management etc to provide maximum boost in the performance of the application.

Architecture of Cache system in a Distributed Application

Summary
Caching improves the performance and responsiveness of the application. However, incorrect caching choices and poor caching design can degrade performance and responsiveness as well. Caching has to be used to optimize reference data lookups, avoid network round trips, and avoid unnecessary duplicate processing. To implement caching, you must first decide when to load data into the cache and try to load cache data asynchronously. Consider the following guidelines when designing cache:

• Cache data in a ready to use format when possible, and avoid caching volatile data that changes regularly.
• Avoid caching sensitive information if it is not encrypted.
• Control the size of the objects which are stored on the cache [Storing Large Objects in a Single Cache Item may degrade performance]
• Try Locking when dealing with the same objects between multiple threads
  Output caching has to be used to cache pages that are relatively static. This dramatically improves performance, while still supporting variation based on submitted values and use partial page caching If only parts of the page are relatively static.
• Pool shared resources that are expensive, such as network connections, instead of caching them.