Dieses (erweiterte) Backend speichert Cache Datensätze in Dateien (in einem gewählten Verzeichnis).

Mögliche Optionen sind :

Dieses (erweiterte) Backend speichert die Cache Datensätze in einer SQLite Datenbank.

Mögliche Optionen sind :

Dieses (erweiterte) Backend speichert Cache Datensätze in einem Memcached Server. memcached ist ein hoch-performantes, verteiltes Speicher Objekt Caching System. Um dieses Backend zu benutzen, wird ein Memcached Dämon benötigt und die Memcached PECL Erweiterung.

Vorsicht: mit diesem Backend werden zur Zeit "Marker" nicht unterstützt genauso wie das "doNotTestCacheValidity=true" Argument.

Mögliche Optionen sind :

Dieses (erweiterte) Backend speichert Cache Datensätze im Shared Memory durch die APC (Alternativer PHP Cache) Erweiterung (welche natürlich für die Verwendung dieses Backends benötigt wird).

Vorsicht: mit diesem Backend werden "Marker" zur Zeit nicht unterstützt genauso wie das "doNotTestCacheValidity=true" Argument.

Es gibt keine Optionen für dieses Backend.

Dieses Backend speichert Cache Einträge im Shared Memory durch die XCache Erweiterung (welche natürlich benötigt wird, damit dieses Backend verwendet werden kann).

Achtung: Bei diesem Backend werden "tags" aktuell nicht unterstützt sowie das "doNotTestCacheValidity=true" Argument.

Mögliche Optionen sind:

Dieses Backend verwendet die Content Caching API des Zend Platform Produktes. Natürlich muss man die Zend Platform installiert haben, um dieses Backend verwenden zu können.

Dieses Backend unterstützt Tags, aber nicht den CLEANING_MODE_NOT_MATCHING_TAG Löschmodus.

Bei Definition dieses Backends muß ein Trennzeichen -- '-', '.', ' ', oder '_' -- zwischen den Wörtern 'Zend' und 'Platform' definiert sein wenn die Zend_Cache::factory() Methode verwendet wird:

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

Es gibt keine Optionen für dieses Backend.

Dieses (erweiterte) Backend ist ein Hybrides. Es speichert Cache Einträge in zwei anderen Backends: Ein schnelles (aber limitiertes) wie Apc, Memcache... und ein "langsames" wie File, Sqlite...

Dieses Backend verwendet den Priority Parameter (der auf Frontend Level angegeben wird wenn ein Eintrag gespeichert wird) und den verbleibenden Platz im schnellen Backend um die Verwendung dieser zwei Backends zu optimieren.

Dieses Backend sollte mit Verwendung eines Word Separators -- '-', '.', ' ', oder '_' -- zwischen den Wörtern 'Two' und 'Levels' spezifiziert werden wenn die Zend_Cache::factory() Methode verwendet wird:

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

Vorhandene Optionen sind:

Diese Backends speichern Cacheeinträge indem Sie die Caching Funktionalitäten von Zend Server verwenden.

Achtung: mit diesen Backends werden für den Moment "Tags" nicht unterstützt, wegen dem "doNotTestCacheValidity=true" Argument.

Diese Backends arbeiten nur in einer Zend Server Umgebung für Seiten die über HTTP oder HTTPS angefragt wurden und nicht für Kommandozeilen Ausführung.

Dieses Backend muß durch Verwendung des customBackendNaming Parameter mit TRUE spezifiziert werden wenn die Methode Zend_Cache::factory() verwendet wird:

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

Es gibt keine Optionen für diese Backends.

Dieses Backend arbeitet in Verbindung mit Zend_Cache_Frontend_Capture (diese zwei müssen zusammen verwendet werden) um die Ausgabe von Anfragen als statische Dateien zu speichern. Dies bedeutet das die statischen Dateien bei weiteren Anfragen direkt serviert werden ohne dass PHP oder sogar Zend Framework involviert sind.

Der Vorteil dieses Caches besteht darin das eine starke Verbesserung des Durchsatzes stattfindet weil statische Dateien zurückgegeben werden und keine weitere dynamische Bearbeitung stattfindet. Natürlich gibt es auch einige Nachteile. Der einzige Weg um dynamische Anfragen wieder zu haben besteht darin die gecachten Dateien von anderswo in der Anwendung zu löschen (oder über einen Cronjob wenn das zeitlich abgestimmt werden soll). Es ist auch auf Single-Server Anwendungen begrenzt begrenzt bei denen nur ein Dateisystem verwendet wird. Trotzdem kann es eine große Bedeutung haben wenn man mehr Geschwindigkeit haben will ohne auf Kosten eines Proxies auf einzelnen Maschinen zu setzen.

Bevor die Optionen beschrieben werden sollte man beachten das dies einige Änderungen der Standardwerte in der .htaccess Datei benötigt damit Anfrage auf die staischen Dateien zeigen wenn diese existieren. Hier ist ein Beispiel einer einfachen Anwendung die etwas Inhalt cacht, inklusive zwei spezifischer Feeds welche zusätzliche Behandlung benötigen um einen korrekten Content-Type Header zu schicken:

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]

Das obenstehende nimmt an das statische Dateien im Verzeichnis ./public/cached gecacht werden. Wir betrachten die Einstellung dieses Ortes unter "public_dir" weiter unten.

Durch die Natur des Cachens von statischen Dateien bietet die Backend Klasse zwei zusätzliche Methoden an: remove() und removeRecursively(). Beide akzeptieren eine Anfrage URI welche, wenn Sie mit dem "public_dir" in dem statische Dateien gecacht werden verknüpft wird, und eine vor-gespeicherte Erweiterung angehängt wird, entweder den Namen einer statischen Datei anbietet welche zu löschen ist, oder einen Verzeichnispfad welcher rekursiv zu löschen ist. Durch die Einschränkung von Zend_Cache_Backend_Interface akzeptieren alle anderen Methoden wie save() eine ID welche durch Anwendung von bin2hex() auf eine Anfrage URI berechnet wird.

Durch das Level an dem das statische Cachen arbeitet ist das statische Dateicaching auf eine einfachere Verwendung mit Zend_Controller_Action_Helper_Cache ausgelegt. Dieser Helfer assistiert beim Einstellen welche Aktionen eines Controllers zu cachen sind, mit welchen Tags, und mit welcher Erweiterung. Er bietet auch Methoden für das Entleeren des Caches durch die Anfrage URI oder Tag. Statischen Dateicaching wird auch durch Zend_Cache_Manager unterstützt welcher vorkonfigurierte Konfigurationstemplates für den statischen Cache enthält (als Zend_Cache_Manager::PAGECACHE oder "page"). Die Standardwerte können hierbei wie benötigt konfiguriert werden um einen "public_dir" Ort für das Cachen zu setzen, usw.