Caches leeren und vorwärmen #

Diese Seite ist für Systemadministratoren und Support-Mitarbeitende bei Hosting-Anbietern. Sie beantwortet: welcher Cache für welche Art von Änderung geleert wird, in welcher Reihenfolge, mit welchem Befehl, wie sich das Leeren auf einer ausgelasteten Website verhält und wie Sie eine Website danach vorwärmen, damit die ersten Besucher nicht dafür bezahlen. Die Quellen sind Caches, Kapitel 10, Abschnitt 10.6, Cache-Steuerung aus der Konsole und Caches vorladen.

Inhalt #

1. Welcher Cache für welche Änderung
2. Die Reihenfolge nach einer Codeänderung
3. Die Befehle
4. Leeren auf einer ausgelasteten Website
5. Der Cronjob zum Aufräumen
6. Vorwärmen
7. Wer was geleert hat
8. Checkliste

Welcher Cache für welche Änderung #

Aus Kapitel 10, Was zu leeren ist, mit php bin/php/ezcache.php:

Kompilierte Templates werden nicht mit ihrer Quelle verglichen, es sei denn, [TemplateSettings] DevelopmentMode=enabled, was Live- Websites aus lassen sollten. Unter Velocity starten Sie nach dem Leeren der INI-Caches neu (Worker halten Einstellungen im Speicher) und leeren nach Änderungen an Templates den Antwort-Cache.

Die Reihenfolge nach einer Codeänderung #

Eine Seite, die vom alten Code zwischen dem Leeren eines Caches und dem Neuladen von PHP gerendert wird, wird erneut zwischengespeichert und sieht aus, als hätte die Änderung nicht gewirkt. Die Reihenfolge: INI- und Template-Caches, dann PHP-FPM neu laden und Velocity neu starten, und erst dann die Caches für Inhalte, HTTP, Template-Blöcke und Antworten. exp:velocity deploy tut genau das, mit PASS oder FAIL pro Schritt, auf Velocity und auf Websites nur mit Apache (--no-velocity):

Die Schritte sind aus Engines von Velocity verdichtet.

php bin/php/console exp:velocity deploy --dry-run --allow-root-user
php bin/php/console exp:velocity deploy --allow-root-user

Die Befehle #

Führen Sie sie als Benutzer der Website aus, damit das, was sie neu anlegen, für den Webserver beschreibbar bleibt; als root brauchen sie --allow-root-user. exp:cache endet mit 0, wenn erledigt, mit 1, wenn es gescheitert ist, mit 2 bei einem Bedienungsfehler, was zu Skripten passt.

Hinweis Setup > Caches (/setup/cache, Richtlinie setup/managecache) gibt dem Administrator eines Kunden dieselben Aktionen im Browser, gruppiert, mit Größen und dem Zeitpunkt, wann jeder Cache zuletzt geleert wurde. Die meisten Support-Fragen zu veralteten Seiten enden dort: Leeren Sie den Antwort-Cache von Velocity oder warten Sie einige Sekunden; ist es eine geänderte Einstellung, starten Sie Velocity neu.

Leeren auf einer ausgelasteten Website #

Seit 6.0.15 benennt ein Leeren ein Cache-Verzeichnis in einem Schritt zur Seite um und löscht es von dort (Leeren von Caches, das Verzeichnisse zur Seite verschiebt): Es kehrt auch bei Hunderttausenden von Dateien schnell zurück, und nichts, was in der Zwischenzeit erzeugt wird, wird vom Löschen erfasst. Einstellungen: site.ini [FileSettings] RenameBeforeDelete=enabled und RenameExpiredCaches=enabled (beide mitgeliefert).

Wenn eine Änderung die View-Caches von [ContentSettings] CacheThreshold Knoten oder mehr (250) leeren würde, wird stattdessen der ganze View-Cache als abgelaufen markiert, und das Log meldet Expiring all view cache. Gelegentlich nach einem großen Verschieben ist das erwartet; bei gewöhnlichen Bearbeitungen deutet es auf Beziehungen oder viewcache.ini hin.

Der Cronjob zum Aufräumen #

Das Leeren des View-Caches oder der Template-Blöcke verschiebt nur einen Zeitstempel; die Dateien bleiben also, bis der Cronjob-Teil cache_cleanup sie entfernt (Dateien nach ihrem Ablauf oder älter als cronjob.ini [CacheCleanupSettings] MaxAge, 172800 s; auch Dateien des HTTP-Caches und des Abfrage-Caches). Er läuft pro var-Verzeichnis:

php runcronjobs.php -s site cache_cleanup

Planen Sie ihn für jede Kunden-Website, sonst wächst var/. Siehe Cronjobs.

Vorwärmen #

Beispiele aus den Quellen:

php bin/php/preload.php --siteaccess=site --dry-run
php bin/php/preload.php --apply --siteaccess=site --max-pages=20 --max-depth=1

30 4 * * * cd /path/to/exponential && php bin/php/preload.php --apply --siteaccess=site -q
*/4 * * * * cd /path/to/exponential && php bin/php/warm.php --allow-root-user >> var/log/cache-warm.log 2>&1

• Der Preloader wärmt Dateien vor, die Apache/PHP-FPM und Velocity teilen. Der Antwort-Cache von Velocity behält eine anonyme Seite nur DefaultTtl Sekunden (30), sodass ein Vorwärmen vor den Besuchern dort nicht anhält.
• Seiten für angemeldete Benutzer werden nicht vorgewärmt: Der Lauf ist ein anonymer Besucher.
• Vorwärmen rendert Seiten und kostet daher CPU. Planen Sie es auf einer geteilten Maschine in ruhigen Stunden und versetzt für die Kunden.
• Auf der Testinstallation der Quelle brauchte exp:warm kalt 9,6 s für 142 Seiten und warm 0,3 s (HTTP/2 und Vorwärmen des Caches).

Wer was geleert hat #

Jedes Leeren wird im Prüfprotokoll als system.cache.clear festgehalten, über die Seite, exp:cache und bin/php/ezcache.php gleichermaßen, bei einer Shell mit dem Benutzer des Betriebssystems. Setup > Caches zeigt Benutzern, die den Systemkanal des Audits lesen dürfen, wann und von wem jeder Cache zuletzt geleert wurde (Caches, zuletzt geleert). Der Support kann daher beantworten, wer den Cache geleert hat, bevor die Website langsam wurde.

Checkliste #

• To do: Der Support hat die Tabelle „Welcher Cache für welche Änderung“.
• To do: Ausrollen nutzt exp:velocity deploy oder dieselbe Reihenfolge von Hand.
• To do: cache_cleanup ist für jedes var-Verzeichnis geplant.
• To do: Eine Strategie zum Vorwärmen (Zeitgeber für exp:warm, nächtliches Vorladen, WarmUpURL[]) pro Tarif gewählt und versetzt.
• To do: Der Abfrage-Cache wird nach jeder Wiederherstellung der Datenbank geleert.

Verwandte Seiten #

• Cache-Schichten
• Änderungen ausrollen
• Langsame Website
• Caches vorladen
• Cache-Steuerung aus der Konsole
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.