Ces backends (étendus) stockent les enregistrements de cache dans des fichiers (dans un dossier choisi).

Les options disponibles sont :

Ce backend (étendu) stocke les enregistrements de cache dans une base de donnée SQLite.

Les options disponibles sont :

Ce backend (étendu) stocke les enregistrements de cache dans un serveur memcached. Memcached est un système de cache en mémoire distribuée, de haute performance. Pour utiliser ce backend, vous devez avoir un démon memcached et l'extension PECL memcache.

Attention : avec ce backend, les balises ("tags") ne sont pas supportées pour le moment comme l'argument "doNotTestCacheValidity=true".

Les options disponibles sont :

Ce backend (étendu) stocke les enregistrements de cache dans un serveur memcached. memcached est un système distribué de cache d'objet en mémoire de haute performance. Pour utiliser ce backend, vous avez besoin d'un démon memcached et de l'extension PECL memcached.

Attention: avec ce backend, les balises ("tags") ne sont pas supportées pour le moment comme l'argument "doNotTestCacheValidity=true".

Les options disponibles sont :

Ce backend (étendu) stocke les enregistrements de cache en mémoire partagée grâce à l'extension APC (Alternative PHP Cache) qui est requise pour utiliser ce backend.

Attention: avec ce backend, les balises ("tags") ne sont pas supportées pour le moment comme l'argument "doNotTestCacheValidity=true".

Il n'y a pas d'options pour ce backend.

Ce backend stocke ces enregistrements de cache dans la mémoire partagée à travers l'extension XCache(qui est bien sûr nécessaire pour utiliser ce backend).

Attention : avec ce backend, les balises ("tags") ne sont pas supportées pour le moment comme l'argument "doNotTestCacheValidity=true".

Les options disponibles sont :

Ce backend utilise l'API de cache de contenu de la Zend Platform. Naturellement, pour utiliser ce backend, vous devez avoir installé une Zend Platorm.

Ce backend supporte les balises ("tags") mais ne supporte pas le mode de nettoyage CLEANING_MODE_NOT_MATCHING_TAG.

Spécifiez ce backend en utilisant un séparateur de mot - "-", ".", " " ou "_" - entre les mots "Zend" et "Platform" quand vous utilisez la méthode Zend_Cache::factory() :

$cache = Zend_Cache::factory('Core', 'Zend Platform');

Il n'y a pas d'options pour ce backend.

Ce backend (étendu) est un hybride. Il stocke les enregistrements de cache dans deux autres backends : un rapide (mais limité) comme Apc, Memcache... et un plus "lent" comme File, Sqlite...

Ce backend utilise le paramètre priorité (fourni au niveau du frontend au moment d'un enregistrement) et l'espace restant dans le backend rapide pour optimiser l'utilisation de ces deux backends.

Spécifiez ce backend avec un séparateur de mots - "-", ".", " ", ou "_" - entre les mots "Two" et "Levels" quand vous utilisez la méthode Zend_Cache::factory() :

$cache = Zend_Cache::factory('Core', 'Two Levels');

Les options disponibles sont :

Ces backends utilisent les fonctionnalités de mise en cache de Zend Serverpour stocker les données.

Attention : avec ces backends ne supportent pas les balises ("tags") pour le moment de même que l'argument "doNotTestCacheValidity=true".

Ces backends fonctionnent seulement dans l'environnement de Zend Server pour les pages requêtées à travers HTTP ou HTTPS et ne fonctionnent pas pour les scripts exécutés en ligne de commande.

Spécifiez ce backend en utilisant le paramètre customBackendNaming à TRUE quand vous utilisez la méthode Zend_Cache::factory() :

$cache = Zend_Cache::factory('Core', 'Zend_Cache_Backend_ZendServer_Disk',
                             $frontendOptions, $backendOptions, false, true);

Il n'y a pas d'options pour ce backend.

This backend works in concert with Zend_Cache_Frontend_Capture (the two must be used together) to save the output from requests as static files. This means the static files are served directly on subsequent requests without any involvement of PHP or Zend Framework at all.

The benefits of this cache include a large throughput increase since all subsequent requests return the static file and don't need any dynamic processing. Of course this also has some disadvantages. The only way to retry the dynamic request is to purge the cached file from elsewhere in the application (or via a cronjob if timed). It is also restricted to single-server applications where only one filesystem is used. Nevertheless, it can be a powerful means of getting more performance without incurring the cost of a proxy on single machines.

Before describing its options, you should note this needs some changes to the default .htaccess file in order for requests to be directed to the static files if they exist. Here's an example of a simple application caching some content, including two specific feeds which need additional treatment to serve a correct Content-Type header:

AddType application/rss+xml .xml
AddType application/atom+xml .xml

RewriteEngine On

RewriteCond %{REQUEST_URI} feed/rss$
RewriteCond %{DOCUMENT_ROOT}/cached/%{REQUEST_URI}.xml -f
RewriteRule .* cached/%{REQUEST_URI}.xml [L,T=application/rss+xml]

RewriteCond %{REQUEST_URI} feed/atom$
RewriteCond %{DOCUMENT_ROOT}/cached/%{REQUEST_URI}.xml -f
RewriteRule .* cached/%{REQUEST_URI}.xml [L,T=application/atom+xml]

RewriteCond %{DOCUMENT_ROOT}/cached/index.html -f
RewriteRule ^/*$ cached/index.html [L]
RewriteCond %{DOCUMENT_ROOT}/cached/%{REQUEST_URI}.(html|xml|json|opml|svg) -f
RewriteRule .* cached/%{REQUEST_URI}.%1 [L]

RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [NC,L]

RewriteRule ^.*$ index.php [NC,L]

The above assumes static files are cached to the directory ./public/cached. We'll cover the option setting this location, "public_dir", below.

Due to the nature of static file caching, the backend class offers two additional methods: remove() and removeRecursively(). Both accept a request URI, which when mapped to the "public_dir" where static files are cached, and has a pre-stored extension appended, provides the name of either a static file to delete, or a directory path to delete recursively. Due to the restraints of Zend_Cache_Backend_Interface, all other methods such as save() accept an ID which is calculated by applying bin2hex() to a request URI.

Given the level at which static caching operates, static file caching is addressed for simpler use with the Zend_Controller_Action_Helper_Cache action helper. This helper assists in setting which actions of a controller to cache, with what tags, and with which extension. It also offers methods for purging the cache by request URI or tag. Static file caching is also assisted by Zend_Cache_Manager which includes pre-configured configuration templates for a static cache (as Zend_Cache_Manager::PAGECACHE or "page"). The defaults therein can be configured as needed to set up a "public_dir" location for caching, etc.