Best Practices With PEAR Cache Lite

Caching a website using PEAR Cache Lite has many benefits – it will speed up your site and is very simple to implement. However, there are several common pitfalls they could cause potential issues on a website. Basically, you can’t approach caching from a single angle, as the type of caching used is always project/problem specific.

Full File Level Caching

Full file caching is the simplist method and essentially takes an image of the page at a particular time. This method is very fast to implement but does have it’s downsides. As you are storing a static file of the page you’ll instantly notice the following issues (I’ve included some typical examples you’ll run into):

• Any elements of your page that require session data will fail to work (you’ve essentially cached the session id too!)
• If the page needs to be served using a particular header you’ll be out of luck, as a statiuc file will always be served using a plain text header (E.g. a cached rss feed won’t validate as the header has changed)
• Clearing the cache becomes very clumsey as the whole cache requires cleaning when even a small change is made (E.g. say a new article is added by the admin)
• User logins that make use of session data
• E-Commerce sites and a shopping basket summary
• Search results pages

With full file caching dynamic content will always be a issue. However, full file caching CAN help high traffic sites, even when a short cache lifetime is set – use with caution!

Block Level or Partial File Caching

Block level caching is likely to be a much longer term caching solution. It is more likely that you’ll have certain sections of a site that do not require an up to date minute. For example, say we have an ecommerce store with dropdown menu that list our full category structure from a database – this is likely to be highly database intensive and may use recursion. This output can be cached to a flat file as follows:

$options = array(
    'cacheDir' => '/cached/',
    'lifeTime' => 1000
);

$cache = new Cache_Lite_Output($options);

if (!$cache->start('left_category_structure')) {
   $store->list_full_category_structure();
   $cache->end();
}

This is much better than full file caching for several reasons:

• The page in question can remain dynamic dynamic elements such as the user’s login status on another part of the page
• If a change is made to the category structure I can delete that particular section of the cache only (the rest of the cache does not require regenerating!)
• The cache lifetime can be set on a per block basis – useful for different types of content
• Even if the category structure doesn’t change often, the block could still be cache forever (set cacheLifeTime to null in the options array) and cleaned when a change is made

Taking Partial Caching Further

PEAR Cache_LIte is also fairly flexible and you can make it fit your needs. For example, say we wanted to cache 10 random articles on a website – which consists of a database query that fetches 10 random articles from a database. The idea here is to still cache the content in a block as above. However, for this our system would create a number of cache blocks and then service those cached blocks to the user. The solution is a simple one, building on the example from above:

$options = array(
    'cacheDir' => '/cached/',
    'lifeTime' => 1000
);

$cache = new Cache_Lite_Output($options);

if (!$cache->start( 'left_category_structure . rand(1,5))) {
   $store->list_full_category_structure();
   $cache->end();
}

When the user requests a page, 5 different cache blocks will be checked – we are essentially creating 5 different versions of the random cached content.