Data Caching for Web Applications

Increase performance and scalability with these data-caching tips

All good e-commerce sites are data-driven, but some data-driven Websites can't quickly serve data because of bad database design, inefficient code accessing the database, heavy server load, and so on. In particular, many e-commerce sites have run into the following problem: They rely on custom COM objects to retrieve data from a database or other data source, and the COM object usually isn't free-threaded (it can't be if it's written in Visual Basic—VB—6.0 or earlier) but apartment-threaded.

Reliance on apartment-threaded COM objects causes large performance penalties to your Web server because each page request requires the creation and subsequent destruction of a COM object. The constant process of creating and destroying COM objects at every page request eats up many CPU cycles even if the object is running in the context of a COM+ application. In addition, the database needs to service all the data requests, the network needs to accommodate high traffic, and so on. All of these factors lead to diminished scalability for your Web application.

To solve this problem, you could write your own data-caching mechanism and ensure that all your data objects are thread-safe. A better way to retrieve relatively constant data is to use caching objects to cache the data as you retrieve it. Caching objects come with the Commerce Server 2000 object model and are relatively easy to use. ASP.NET also has a powerful, easy-to-use caching mechanism.

A good design pattern to follow is to cache as much frequently used data as possible when your Web application starts up by using the Application_OnStart method in the global.asa file. Then, every time yousend a request for data, make sure to check the cache first. Examples of cacheable data on an e-commerce site are product catalog data, certain look-up lists (such as countries, states, and the results from common search phrases), and any other relatively static data in a data store. If you can't get your data from the cache, then you simply retrieve it from the data source and cache the data as soon as you retrieve it.

Also, instead of creating an instance of an object to get your data from the cache at every page request, you can simply put the object (as long as it's thread-safe!) into a Microsoft IIS application-level variable. The caching objects in Commerce Server 2000 and the caching classes in ASP.NET are already thread-safe. If you use this approach, the object will be created only once when the application starts, and the data will come from a cache.

If the data in the data source changes, you need to refresh the appropriate caches. In ASP.NET, the System.Web.Caching namespace provides classes for caching, dictionary classes to store the data caches, and even delegate classes for calling back to caches when the data source has changed. These classes give you almost every resource you need and will save you many hours of coding time.

RAM is especially cheap these days, so why not take advantage of it in your applications? Put as much data into memory in your Web application as makes sense. The performance benefits will far outweigh the small costs for the extra memory. Most current Web servers have at least 500MB to 1GB of RAM, which will accommodate enough data in memory for a typical e-commerce site selling less than 100,000 items in its product catalog. The cost of the memory is a small price to pay for the benefits that your site will realize.