Caching Strategies

 

Retrieving data from a database is certainly slower than retrieving cached data from memory, however, caching is not for all types of applications. An application that needs to provide up-to–date information can hardly exploit caching or, at least, can afford caching for a limited amount of time only. The less time you hold data in memory, the less benefit you get from caching. However, the longer time you cache a value, the more stale it becomes. An application-specific tradeoff is mandatory to make a decision.

In ASP.NET, the built-in caching mechanism—the Cache object—is particularly efficient and effective, but this fact alone is insufficient to make caching great for everybody. The Cache object makes implementing a cache of global data particularly easy, but it doesn't make caching affordable for all applications. This may sound obvious, but it is a frequent source of poor design.

While evaluating the pros and the cons of caching for your application, consider data retrieval on one side and speed of access on the other. Mediate the results with the needed refresh frequency and you have the magic formula.

For ASP.NET applications, caching is particularly effective for frequently used global data, such as lookup tables. Caching is less recommended for session-specific data, which would more significantly affect the scalability of the application. Also, the Cache object is of no use in a Web farm scenario and can compromise overall performance in the case of Web gardens. This is mostly due to the particular use of multiple processors made by the ASP.NET worker process. When the Web garden model is enabled, the worker process is cloned per processor. The application data is duplicated, although global objects are stored in shared memory. For applications holding a lot of state in the Cache object, the Web garden can be a risky model.

The second consideration relates to the excellent SQL Server internal cache mechanism, which allows for a good deal of reuse for repeated queries and stored procedures. By avoiding or limiting the application's use of the cache, you make your application inherently more scalable horizontally (scale-out) because you can port it to a Web farm more easily. By extensively using the cache, your application is inherently more scalable vertically (scale-up) and better capable of exploiting faster machines—but not necessarily multi-processor machines.