Rozdział 2. Zend_Cache

Spis treści

2.1. Introduction
2.2. The theory of caching
2.2.1. The Zend_Cache factory method
2.2.2. Tagging records
2.2.3. Cleaning the cache
2.3. Zend_Cache frontends
2.3.1. Zend_Cache_Core
2.3.2. Zend_Cache_Frontend_Output
2.3.3. Zend_Cache_Frontend_Function
2.3.4. Zend_Cache_Frontend_Class
2.3.5. Zend_Cache_Frontend_File
2.3.6. Zend_Cache_Frontend_Page
2.4. Zend_Cache backends
2.4.1. Zend_Cache_Backend_File
2.4.2. Zend_Cache_Backend_Sqlite
2.4.3. Zend_Cache_Backend_Memcached
2.4.4. Zend_Cache_Backend_APC

2.1. Introduction

Zend_Cache provides a generic way to cache any data.

Caching in Zend Framework is operated by frontends while cache records are stored through backend adapters (File, Sqlite, Memcache...) through a flexible system of IDs and tags. Using those, it is easy to delete specific types of records afterwards (for example: "delete all cache records marked with a given tag").

The core of the module (Zend_Cache_Core) is generic, flexible and configurable. Yet, for your specific needs there are cache frontends that extend Zend_Cache_Core for convinience: Output, File, Function and Class.

Przykład 2.1. Getting a frontend with Zend_Cache::factory()

Zend_Cache::factory() instantiates correct objects and ties them together. In this first example, we will use Core frontend together with File backend.

require_once 'Zend/Cache.php';

$frontendOptions = array(
   'lifeTime' => 7200, // cache lifetime of 2 hours 
   'automaticSerialization' => true

$backendOptions = array(
    'cacheDir' => './tmp/' // Directory where to put the cache files

// getting a Zend_Cache_Core object
$cache = Zend_Cache::factory('Core', 'File', $frontendOptions, $backendOptions);


Now that we have a frontend, we can cache any type of data (we turned on serialization). For example, we can cache a result from a very expensive database query. After it is cached, there is no need to even connect to the database; records are fetched from cache and unserialized.


// $cache initialized in previous example

// see if a cache already exists:
if(!$result = $cache->get('myresult')) {

    // cache miss; connect to the database
    $db = Zend_Db::factory( [...] );
    $result = $db->fetchAll('SELECT * FROM huge_table');
    $cache->save($result, 'myresult');
} else {

    // cache hit! shout so that we know
    echo "This one is from cache!\n\n";



Przykład 2.2. Caching output with Zend_Cache output frontend

We 'mark up' sections in which we want to cache output by adding some conditional logic, encapsulating the section within start() and end() methods (this resembles the first example and is the core strategy for caching).

Inside, output your data as usual - all output will be cached when execution hits the end() method. On the next run, the whole section will be skipped in favor of fetching data from cache (as long as the cache record is valid).


$frontendOptions = array(
   'lifeTime' => 30,                  // cache lifetime of half a minute
   'automaticSerialization' => false  // this is default anyway

$backendOptions = array('cacheDir' => './tmp/');

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

// we pass a unique identifier to the start() method
if(!$cache->start('mypage')) {
    // output as usual:
    echo 'Hello world! ';
    echo 'This is cached ('.time().') ';
    $cache->end(); // the output is saved and sent to the browser

echo 'This is never cached ('.time().').';


Notice that we output the result of time() twice; this is something dynamic for demonstration purposes. Try running this and then refreshing several times; you will notice that the first number doesn't change while second changes as time passes. That is because the first number was output in the cached section and is saved among other output. After half a minute (we've set lifetime to 30 seconds) the numbers should match again because the cache record expired -- only to be cached again. You should try this in your brower or console.

[Notatka] Notatka

When using Zend_Cache, pay attention to the important cache identifier (passed to save() and start()). It must be unique for every resource you cache, otherwise unrelated cache records may wipe each other or, even worse, be displayed in place of the other.