Este backend (extendido) almacena los registros de caché en archivos (en un directorio elegido).

Las opciones disponibles son:

Este backend (extendido) almacena los registros de caché en una base de datos SQLite.

Las opciones disponibles son:

Este backend (extendido) almacena los registros de caché en un servidor memcached. memcached es un sistema de caché de objetos en memoria distribuido de alto rendimiento. Para usar este backend, necesita un demonio memcached y la extensión PECL memcache.

Tenga cuidado: con este backend, las "tags" no son compatibles por el momento, como tampoco el argumento "doNotTestCacheValidity=true".

Las opciones disponibles son:

Este backend (extendido) almacena los registros de caché en un servidor memcached. memcached es un sistema de caché de objetos en memoria distribuido de alto rendimiento. Para usar este backend, necesita un demonio memcached y la extensión PECL memcached.

Tenga cuidado: con este backend, las "tags" no son compatibles por el momento, como tampoco el argumento "doNotTestCacheValidity=true".

Las opciones disponibles son:

Este backend (extendido) almacena los registros de caché en memoria compartida a través de la extensión APC (Alternative PHP Cache) (la cual es, por supuesto, necesaria para usar este backend).

Tenga cuidado: con este backend, las "tags" no son compatibles por el momento, como tampoco el argumento "doNotTestCacheValidity=true".

No hay opciones para este backend.

Este backend almacena los registros de caché en memoria compartida a través de la extensión XCache (la cual es, por supuesto, necesaria para usar este backend).

Tenga cuidado: con este backend, las "tags" no son compatibles por el momento, como tampoco el argumento "doNotTestCacheValidity=true".

Las opciones disponibles son:

Este backend utiliza la API de caché de contenido del producto Zend Platform. Naturalmente, para usar este backend necesita tener instalado Zend Platform.

Este backend admite tags, pero no admite el modo de limpieza CLEANING_MODE_NOT_MATCHING_TAG.

Especifique este backend usando un separador de palabras -- '-', '.', ' ', o '_' -- entre las palabras 'Zend' y 'Platform' al usar el método Zend_Cache::factory():

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

No hay opciones para este backend.

Este backend (extendido) es un híbrido. Almacena los registros de caché en otros dos backends: uno rápido (pero limitado) como Apc, Memcache... y uno "lento" como File, Sqlite...

Este backend utilizará el parámetro de prioridad (dado a nivel del frontend al almacenar un registro) y el espacio restante en el backend rápido para optimizar el uso de estos dos backends.

Especifique este backend usando un separador de palabras -- '-', '.', ' ', o '_' -- entre las palabras 'Two' y 'Levels' al usar el método Zend_Cache::factory():

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

Las opciones disponibles son:

Estos backends almacenan los registros de caché utilizando la funcionalidad de caché de Zend Server.

Tenga cuidado: con estos backends, las "tags" no son compatibles por el momento, como tampoco el argumento "doNotTestCacheValidity=true".

Estos backends solo funcionan dentro del entorno de Zend Server para páginas solicitadas a través de HTTP o HTTPS y no funcionan para la ejecución de scripts en línea de comandos

Especifique este backend usando el parámetro customBackendNaming como TRUE al usar el método Zend_Cache::factory():

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

No hay opciones para este backend.

Este backend funciona junto con Zend_Cache_Frontend_Capture (los dos deben usarse conjuntamente) para guardar la salida de las peticiones como archivos estáticos. Esto significa que los archivos estáticos se sirven directamente en peticiones posteriores sin ninguna intervención de PHP o de Zend Framework.

Nota

Zend_Cache_Frontend_Capture opera registrando una función de callback que se llama cuando se limpia el buffer de salida que utiliza. Para que esto funcione correctamente, debe ser el buffer de salida final de la petición. Para garantizar esto, el buffering de salida usado por el Dispatcher debe desactivarse llamando al método setParam() de Zend_Controller_Front, por ejemplo, $front->setParam('disableOutputBuffering', true); o añadiendo "resources.frontcontroller.params.disableOutputBuffering = true" a su archivo de configuración del bootstrap (asumiendo INI) si utiliza Zend_Application.

Los beneficios de esta caché incluyen un gran aumento del rendimiento, ya que todas las peticiones posteriores devuelven el archivo estático y no necesitan ningún procesamiento dinámico. Por supuesto, esto también tiene algunas desventajas. La única forma de volver a intentar la petición dinámica es purgar el archivo cacheado desde algún otro lugar de la aplicación (o mediante un cronjob si está temporizado). También está restringido a aplicaciones de un único servidor donde solo se usa un sistema de archivos. Sin embargo, puede ser un medio poderoso para obtener más rendimiento sin incurrir en el coste de un proxy en máquinas únicas.

Antes de describir sus opciones, debe tener en cuenta que esto necesita algunos cambios en el archivo .htaccess predeterminado para que las peticiones se dirijan a los archivos estáticos si existen. Aquí tiene un ejemplo de una aplicación sencilla que cachea contenido, incluyendo dos feeds específicos que necesitan tratamiento adicional para servir una cabecera Content-Type correcta:

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]

Lo anterior asume que los archivos estáticos se cachean en el directorio ./public/cached. Cubriremos la opción que configura esta ubicación, "public_dir", más adelante.

Debido a la naturaleza del cacheo de archivos estáticos, la clase del backend ofrece dos métodos adicionales: remove() y removeRecursively(). Ambos aceptan una URI de petición que, cuando se mapea al "public_dir" donde se cachean los archivos estáticos, y tiene añadida una extensión previamente almacenada, proporciona el nombre de un archivo estático a eliminar, o una ruta de directorio a eliminar recursivamente. Debido a las restricciones de Zend_Cache_Backend_Interface, todos los demás métodos como save() aceptan un ID que se calcula aplicando bin2hex() a una URI de petición.

Dado el nivel en el que opera el cacheo estático, este se aborda para un uso más sencillo con el helper de acción Zend_Controller_Action_Helper_Cache. Este helper ayuda a establecer qué acciones de un controlador cachear, con qué tags y con qué extensión. También ofrece métodos para purgar la caché por URI de petición o por tag. El cacheo de archivos estáticos también se ve asistido por Zend_Cache_Manager, que incluye plantillas de configuración preconfiguradas para una caché estática (como Zend_Cache_Manager::PAGECACHE o "page"). Los valores predeterminados de estas pueden configurarse según sea necesario para establecer una ubicación "public_dir" para el cacheo, etc.

Nota

Debe tenerse en cuenta que la caché estática en realidad utiliza una caché secundaria para almacenar los tags (obviamente no podemos almacenarlos en otro lugar ya que una caché estática no invoca PHP si funciona correctamente). Esta es simplemente una caché Core estándar, y debería usar un backend persistente como File o TwoLevels (para aprovechar el almacenamiento en memoria sin sacrificar la persistencia permanente). El backend incluye la opción "tag_cache" para configurar esto (es obligatoria), o el método setInnerCache().