Zend Cache Extension

The Zend Cache Extension is a collection of APIs for realizing advanced partial caching capabilities. This API complementary addition to the existing "full page caching" and "partial page caching".

The Zend Cache API extends caching capabilities to include the following functionality:

All functions can be used to Cache using Memory or Disk.

A complete list of the Zend Cache APIs and Directives can be found in the References section.

Disk/Shared-Memory Caching

This feature provides the options to determine where to store cached variables. Memory caching improves server responsiveness primarily in environments that are running high-traffic applications that need to off-load activity directed towards their Hard Disk in order to help increase performance and responsiveness. Disk caching is more suitable for smaller applications and also ensures the cached content is available after restarting the machine.


SHM/Disk storage is implemented by using the appropriate API functions and configuring the Zend Cache directives.


The memory option error messages have been put into place to maintain that if you run out of allocated memory or the store operation fails you will be notified.

Usage Example


The following example shows the different storage options:

A simple key with no namespace stored on disk

if (zend_disk_cache_store("hello1", 1) === false){

    echo "error2\n";    exit();


Shared memory:

if (zend_shm_cache_store("hello1", 1) === false){

    echo "error2\n";    exit();


Store with namespace on disk

if (zend_disk_cache_store("ns1::hello1", 1) === false){

    echo "error2\n";    exit();


Shared memory:

if (zend_shm_cache_store("ns1::hello1", 1) === false){

    echo "error2\n";    exit();



Store with namespace on disk with limited lifetime (3)

if (zend_disk_cache_store("ns3::test_ttl", 2, 3) === false){

    echo "error12\n";    exit();


Shared memory:

if (zend_shm_cache_store("ns3::test_ttl", 2, 3) === false){

    echo "error12\n";    exit();



'namespace' Support

Using 'namespaces' for caching provides the ability define a key that will serve as an identifier to delete select items from the cache rather than unnecessarily removing shared instances. 'namespace' support is intended for environments running large applications that are separated into modules. Applying a 'namespace' to each module will provide the identification necessary to pinpoint all cached items belonging to a given module and remove only them.


Naturally this does not mean that in order to clear the cache you will need to use the 'namespaces' as there is still the option to clear the entire cache using the 'output_cache_remove' functions

Setting the cached 'namespace':

Cache name space could be set by adding it as a prefix to the cache with '::' as separator.

Usage Example


This example shows how to manipulate variable caching using a 'namespace'

zend_cache_store("my_namespace::my_key",$data) can be fetched with zend_cache_fetch("my_namespace::my_key");

zend_cache_clear("my_namespace") will clear all the keys starting with "my_namespace::")


Cache Folder Depth Configuration

Defining the Cache folder depth is intended for environments that use a large amount of keys. By definition, cached content is separated into different directories by key to prevent performance degradation caused by accessing files containing  large amounts of content. This option is only available with Disk Caching. Increase the cache folder depth according to the quantity of content that requires caching (small amount = 0, large quantities = 2).


A single directory may include several keys depending on the quantity of cached content.

The cache folder depth is defined by the directive: zend_cache.disk.dir_levels. The accepted values are 0,1,2 the values represent the levels that the cached files are stored.

0 = one directory containing all the Cache files

1 = a separate directory under the Cache directory

2 = an additional sub directory for cached content under the cache directory

ETag/"Last modified" headers support

On the first request to the server, the server sends the client 'Last-Modified' entity-header field containing the time-stamp, that is, the time when the page was created.

If the client makes a conditional request for the content by sending an 'If-Modified-Since' header (or If-Unmodified-Since header), when the server gets the request, one of the following occurs:

The server validates the requests against the current validator for the entity, and if there is a match then the cache is valid and it can be used by the client. In this case, the server responds with a special status code 304 (Not Modified) and no entity-body - i.e. it doesn't send the actual body. In this case, the client will use the content from the local cache.

#Otherwise, the cache has expired, and a new content is returned to the client.


Cache tag is a feature of HTTP usually implemented by proxy or reverse proxy servers, that enables the server to identify content (page) by an identifier or tag. It uses attributes in the HTTP headers (see detailed requirements section for more details). On the client side, this feature is supported out-of-the-box in all modern browsers.

If the same URL is requested again, the tag is sent in the request. The server can decide whether to send the entire content again (if it was changed for example) or to reply with an HTTP 304 response, meaning the content is unchanged. In such case, the response does not include the body in the content and the content is fetched from the browser's cache.

For Platform 3.5, only the HTTP Caching Validation model is to be implemented.

The Expiration Model may raise some inconsistencies when content on the server-side is updated or 'clear-cached'.

Detailed Requirements

Full information can be found at HTTP RFC 2616 Chapter 13 - Caching in HTTP: [1] (http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html)

Basically, there are 2 models of client-side caching utilization in HTTP - Expiration Model; Validation Model - where E-tags can be used in the latter one.


E-tag (Entity tag) response-headers are used in order to implement this functionality. It provides a more reliable validation in situations where it is inconvenient to store modification dates. That is, instead of working with time-stamps in the attributes mentioned above, entity tags, that are identifiers for the server, are put for any content. E-tags are used as request validators and they are put in one of the following header fields:

Pros: More safe on the server.

Cons: more complex to be implemented, a bit more efficient.



Related Links

Related Links:
File View

Dynamic Content Caching

Partial and Preemptive Page Caching

Zend Cache Functions

Zend Cache Directives