Caching für CMS-Entwickler #

Diese Seite richtet sich an Entwickler, die schnelle Seiten ohne veraltete Seiten wollen. Exponential speichert auf mehreren Ebenen zwischen; die meisten funktionieren ohne Ihr Zutun, und die übrigen brauchen eine Entscheidung in Ihren Templates. Die beiden Fragen, die Sie in jedem Projekt beantworten, sind: Was darf zwischen Besuchern geteilt werden und welcher Cache muss nach welcher Änderung weg.

Inhalt #

1. Die Ebenen
2. Der View-Cache
3. Cache-Blöcke
4. Was das Veröffentlichen leert
5. Caches für Code und Einstellungen
6. Ganze Seiten: HTTP-Cache und Velocity
7. Welcher Cache nach welcher Änderung
8. Besucherbezogene Ausgaben
9. Sehen, was zwischengespeichert ist

Die Ebenen #

Jede Ebene, mit ihrem Ort und wie sie geleert wird: Caching-Ebenen.

Der View-Cache #

CachedViewModes=full;sitemap;pdf: Diese Ansichtsmodi werden, als Seiten geöffnet, gespeichert. Das Pagelayout ist nicht im View-Cache; es läuft bei jeder Anfrage um den zwischengespeicherten Inhalt herum. Eine zwischengespeicherte Ansicht ist nach Knoten, Ansichtsmodus, Sprache, Rollen und Einschränkungen des Benutzers, View-Parametern und mehr geschlüsselt (kernel/classes/eznodeviewfunctions.php), sodass Besucher mit unterschiedlichen Rechten unterschiedliche Kopien erhalten.

Ein Full-View-Template kann seine eigene Lebensdauer setzen: {set-block scope=root variable=cache_ttl}400{/set-block} hält diese Seite 400 Sekunden, nützlich für eine Seite, die mit currentdate() vergleicht. ViewCacheTweaks[<node id>] in site.ini hat Optionen je Knoten, etwa ein Caching je Benutzer (Caching für Designer).

Cache-Blöcke #

Schließen Sie teure Teile des Pagelayouts (Menüs, Fußzeilen) in einen Cache-Block ein, mit jedem Wert, der die Ausgabe ändert, in seinen Schlüsseln:

{cache-block keys=array( $module_result.uri, $current_user.role_id_list|implode( ',' ) ) subtree_expiry=$menu_root_node_id}
    {include uri='design:parts/main_menu.tpl'}
{/cache-block}

Ohne keys gibt es eine Kopie für jede Seite und jeden Besucher. Standardmäßig verfällt ein Block nach 7200 Sekunden und bei jedem Veröffentlichen; subtree_expiry lässt ihn nur bei Veröffentlichungen unter einem Knoten verfallen, ignore_content_expiry nie beim Veröffentlichen (Cache-Block).

Was das Veröffentlichen leert #

Das Veröffentlichen leert den View-Cache der Knoten des Objekts, ihrer übergeordneten Knoten und verknüpfter Objekte nach den Relationstypen in viewcache.ini [ViewCacheSettings] ClearRelationTypes[] (mitgeliefert common, reverse_common, reverse_embedded). SmartCacheClear=disabled wird mitgeliefert; eingeschaltet leeren Regeln je Klasse mehr, zum Beispiel die Startseite, wenn ein Artikel veröffentlicht wird. Eine Startseite, die die neuesten Artikel listet, wird beim Veröffentlichen eines davon nur geleert, wenn eine Regel oder eine Relation sie verbindet; geben Sie Listenseiten also eine kurze cache_ttl oder eine Regel zum intelligenten Leeren.

Caches für Code und Einstellungen #

Velocity hält Einstellungen und Klassen in seinen Workern: Starten Sie es nach INI- oder PHP-Änderungen neu (Caches: was jeder enthält).

Ganze Seiten: HTTP-Cache und Velocity #

Der HTTP-Cache und der Antwort-Cache von Velocity halten ganze Antworten; eine Seite, die aus ihnen kommt, erreicht PHP nie. Leeren Sie den von Velocity nach Template-Änderungen mit ./console exp:velocity cache clear --apply, und zwar immer nachdem die PHP-Worker den neuen Code ausführen, sonst wird eine vom alten Code gerenderte Seite erneut zwischengespeichert (HTTP-Cache, Antwort-Cache von Velocity). Der statische Cache ist in neuen Installationen aus; lassen Sie ihn aus, sofern Sie keinen Bedarf gemessen haben.

Welcher Cache nach welcher Änderung #

Setup > Caches in der Administration listet jeden Cache mit seiner ID, seiner Größe und dem Befehl, der ihn leert, und ./console exp:cache clear --id=<id> --dry-run zeigt, was wegfallen würde. Lesen Sie im Zweifel Warum erscheint meine Änderung nicht? und Caches nach einer Änderung, bevor Sie alles leeren: --clear-all auf einer viel besuchten Website lässt jeden Besucher warten, während die Caches neu aufgebaut werden.

Besucherbezogene Ausgaben #

Der häufigste Caching-Fehler ist der Name, der Warenkorb oder die Schaltfläche "Bearbeiten" eines Besuchers, die zwischengespeichert und dem nächsten Besucher gezeigt werden.

• Legen Sie besucherbezogene Teile in das Pagelayout (nicht im View-Cache), in einem Cache-Block nach Benutzer geschlüsselt, oder lassen Sie sie ungecacht.
• Geben Sie in einer Full View nur aus, was für alle mit denselben Rollen gleich ist.
• Schlüsseln Sie einen Cache-Block nie nach etwas, das ein Besucher ohne Grenzen steuert (einem freien Textparameter): Das füllt die Festplatte.

Sehen, was zwischengespeichert ist #

./console exp:cache status --allow-root-user
./console exp:cache clear --id=content --dry-run --allow-root-user

status gibt eine Zeile je Ebene aus; die Debug-Ausgabe zeigt, ob eine Ansicht aus dem Cache kam. Die Arbeit an der Leistung beginnt hier: Leistung.

Verwandte Seiten #

• Template-Kompilierung und Cache
• Cache-Tags und Leeren
• Caching und Templates für Website-Bauer
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.