Recognizing Cacheable Data Components
The first trick in adding caching to an application is to determine which data is cacheable. When analyzing an application, I start with the following list, which roughly moves from easiest to cache to most difficult to cache:
What pages are completely static? If a page is dynamic but depends entirely on static data, it is functionally static. What pages are static for a decent period of time? "A decent period" is intentionally vague and is highly dependent on the frequency of page accesses. For almost any site, days or hours fits. The front page of www.cnn.com updates every few minutes (and minute-by-minute during a crisis). Relative to the site's traffic, this qualifies as "a decent period." What data is completely static (for example, reference tables)? What data is static for a decent period of time? In many sites, a user's personal data will likely be static across his or her visit.
The key to successful caching is cache locality. Cache locality is the ratio of cache read hits to cache read attempts. With a good degree of cache locality, you usually find objects that you are looking for in the cache, which reduces the cost of the access. With poor cache locality, you often look for a cached object but fail to find it, which means you have no performance improvement and in fact have a performance decrease.
|
