One of the nice things about the Zend Framework is that most of its libraries can be used either from within the framework or as stadalone bits of code which can be seamlessly integrated into non-Zend applications.  Zend_Cache is no exception and can be used to quickly apply caching solutions to common performance problems.  If you are new to caching, or wondering what caching is, it is simply a technique by which something is stored to avoid running the same code over and over again.  For example, if you have a query that is going to be launched time and time again and the result is not going to vary, we can cache it and run it only once, retrieving the cached result until the cache expires thus saving the database a lot of stress.

The hardest part to understand about Zend_Cache is its collection of frontends and backends.  Since the aim of this article is to provide an introduction into quickly deploying a caching solution I will not cover all the options, but they are perfectly covered in the Zend_Cache framework documentation.  However, once we go past the tricky names we can see that a frontend is merely a way to specify what we want to store in cache, and a backend they to specify how.

Zend_Cache can store virtually anything from php objects to pages or functions and, out of the box, supports storage "mediums" such as filesystem, Sqlite, Memcache or Apc among many others.  Again, the documentation provides full reference, but for the purpose of this tutorial we will concentrate on the Core frontend (a generic container of text) and the File backend.  Why?  Because it is the most widely available solution and a good way to get started with Zend_Cache.  If you are interested in other options please comment and I will address them.

Now let's see a simple instantiation of a cache object:

$frontendOptions = array(
    'lifetime' => 3600, // cache lifetime of 1 hour
    'automatic_serialization' => true
);
$backendOptions = array();

$cache = Zend_Cache::factory('Core',
                             'File',
                             $frontendOptions,
                             $backendOptions);

Let's take a look at what we've done.  First, we've defined the option values that will define the behavior of the frontend.  In this case we've given the cached items a lifespan of one hour and we've set the automatic serialization option to true which guarantees the Core frontend becomes a pretty safe container of virtually anything.  Secondly, we've defined the option values for the backend.  In this case I've left it empty since default values are the most generic and work fairly well.  Otherwise, we can change where the files containing the objects are stored, whether they should be locked, whether there should be read control etc...  And finally we create the cache object using the Zend_Cache factory method.  Voilà!  Now let's take a peek on how it's used:

if (!$obj = $cache->load('Object_Expensive_To_Generate')) {
    $obj = new ObjectThatIsExpensiveToGenerate();
    $obj->overloadDatabaseWithExpensiveQueries();
    $obj->hogTheCpu();

    $cache->save($obj, 'Object_Expensive_To_Generate');
}

Woohoo!  Now we only get to go through the painful process of generating an ObjectThatIsExpensiveToGenerate once an hour.  Now let's take a peek at what we've done...  If the object has not yet been cached, or it has expired, the condition in the if clause will return true, and hence start generating and instance of the object.  However, if it has been cached it will skip the if altogether and leave us with a perfectly functional $obj at the other side without going through all the hassle and thus saving valuable resources.  If we do enter the conditional though, the last thing we do is to put the object in cache so we can safely retrieve it for the next hour.

And now that we've finished this brief introduction into Zend_Cache and caching in general, it's time to apply it or to delve deeper and explore what this powerful class has to offer!