Caching für Verfügbarkeit #

Diese Seite richtet sich an Führungskräfte, die wollen, dass die Website erreichbar bleibt, wenn viele Kunden gleichzeitig kommen, und an die Person im Betrieb, die die Caches konfiguriert. Sie erklärt, warum Caching eine Maßnahme für Zuverlässigkeit ist, welche Schichten Exponential bietet, was ab Werk eingeschaltet ist und welche wenigen Regeln verhindern, dass Caches selbst Probleme verursachen. Die vollständige technische Übersicht finden Sie unter Cache-Schichten und Caches.

Inhalt #

1. Warum Caching eine Maßnahme für Zuverlässigkeit ist
2. Die Schichten in einfachen Worten
3. Was ab Werk eingeschaltet ist
4. Im Cache eingebauter Schutz
5. Angemeldete Kunden
6. Caches sicher leeren
7. Vorwärmen nach dem Leeren
8. Checkliste

Warum Caching eine Maßnahme für Zuverlässigkeit ist #

Jede Seite, die aus einem Cache beantwortet wird, braucht weder die Datenbank noch die Template-Engine noch einen PHP-Worker. Das hat zwei Wirkungen, die einem Unternehmen wichtig sind:

• Reserven unter Last. Derselbe Server kann weit mehr Besucher bedienen, wenn die meisten Seiten aus einem Cache kommen, sodass eine Lastspitze seltener zu einem Ausfall wird.
• Weniger bewegliche Teile pro Anfrage. Die Datenbankdokumentation sagt es deutlich: „Die meisten Anfragen erreichen die Datenbank nie“, weil der Antwortcache, der View-Cache und der Template-Block-Cache zuerst antworten (Datenbankunterstützung, Leistung und Skalierung).

Eine Grenze sollten Sie im Kopf behalten: Eine gecachte Startseite kann grün bleiben, während die Datenbank ausgefallen ist. Deshalb lautet die Empfehlung für das Monitoring, auch die Anmeldeseite der Administration zu prüfen (Health-Checks und Monitoring).

Die Schichten in einfachen Worten #

Von außen nach innen (Cache-Schichten, die Schichten auf einen Blick):

Die beiden Schichten, die antworten, ohne die Anwendung überhaupt auszuführen, der statische Cache und der Antwortcache von Velocity, haben eine eigene Seite: Statischer Cache und Antwortcache.

Was ab Werk eingeschaltet ist #

Aus den mitgelieferten Einstellungen (Cache-Schichten, abgeglichen mit settings/site.ini, settings/velocity.ini und settings/querycache.ini):

Setup > Systeminformationen warnt, wenn View-Caching, Template-Kompilierung, der Template-Cache oder der Override-Cache ausgeschaltet ist, und rät, sie „in der Produktion einzuschalten“ (Systeminformationen, Zustandsprüfungen).

Im Cache eingebauter Schutz #

Die README nennt Korrekturen in Exponential 6.0.15, die „überall gelten, wo Exponential läuft“, unter Apache und Nginx ebenso wie unter Velocity (README, „The part that matters even if you never run Velocity“):

• Bedingte Anfragen: „Das Neuladen eines wiederkehrenden Besuchers wird mit 202 Byte statt mit der ganzen Seite beantwortet, weil gecachte Seiten jetzt korrekt auf bedingte Anfragen antworten.“
• Inhaltsbasierte Identität: Der Neuaufbau eines Cache-Eintrags, der identische Ausgabe erzeugt hat, „zwingt nicht mehr jeden Besucher, ihn erneut herunterzuladen“.
• Ein Neuaufbau statt eines Ansturms: „Wenn eine gecachte Seite abläuft, baut eine Anfrage sie neu auf, während alle anderen die vorhandene Kopie erhalten, statt dass jeder anwesende Besucher sie gleichzeitig neu aufbaut.“ Das verhindert, dass eine beliebte Seite den Server in dem Moment überlastet, in dem ihr Cache abläuft.
• Gemerktes „nicht gefunden“: „Ein ‚nicht gefunden‘ wird gemerkt, statt jedes Mal von Grund auf neu aufgebaut zu werden.“

Für ein Unternehmen zählt der dritte Punkt am meisten: Der Moment, in dem auf einer stark besuchten Seite ein Cache abläuft, ist eine klassische Ursache für Überlastung, und Exponential kümmert sich darum für Sie.

Angemeldete Kunden #

Angemeldete Kunden (Mitglieder, Shop-Kunden mit Konto, Redakteure) sehen Seiten, die davon abhängen, wer sie sind. Der Antwortcache von Velocity bedient sie nie: „Angemeldete Besucher werden nie aus dem Cache bedient“ (settings/velocity.ini, [CacheSettings]). Der Content-View-Cache hilft ihnen trotzdem, weil er je Rolle und Einschränkungen gehalten wird (View-Cache und Cache-Blöcke), und der rollenbewusste HTTP-Cache kann angemeldete Besucher je Berechtigungskontext bedienen, wenn er eingeschaltet ist.

Wenn der größte Teil Ihres Verkehrs angemeldet ist (ein Intranet, eine Mitgliederwebsite, ein Shop an der Kasse), planen Sie die Kapazität für gerenderte Seiten, nicht für gecachte (Lastspitzen planen).

Caches sicher leeren #

Caches machen nur Ärger, wenn sie unbedacht geleert werden. Drei Regeln:

1. Leeren Sie das Kleinste, das das Problem behebt. Eine geänderte Einstellung braucht den INI-Cache, ein Template den Template-Cache. „Alles, wenn unsicher“ gibt es, kostet aber die nächsten Besucher je eine langsame Seite (Betrieb einer Site, den richtigen Cache leeren).
2. Erst hinsehen. --dry-run zeigt, was ein Leeren bewirken würde, und ändert nichts.
3. Seiten-Caches zuletzt leeren. „Leeren Sie die HTTP- und Antwortcaches, nachdem PHP-FPM oder Velocity den neuen Code ausführt, sonst wird eine in der Zwischenzeit vom alten Code gerenderte Seite erneut gespeichert“ (dieselbe Seite). Der Deploy-Befehl erledigt das in der richtigen Reihenfolge (Unterbrechungsfreie Deployments).

Große Caches werden zur Seite verschoben und danach gelöscht, „damit ein Leeren Anfragen nicht warten lässt“ (Cache-Leerungen, die Verzeichnisse zur Seite verschieben).

Vorwärmen nach dem Leeren #

Nach einem Leeren oder einem Deployment „bezahlt der erste Besucher für das Rendern“. Wärmen Sie die Seiten selbst vor (Betrieb einer Site, die Site vorwärmen):

php bin/php/preload.php --apply --siteaccess=site --allow-root-user

Verwenden Sie den Namen Ihres eigenen öffentlichen Siteaccess. Dasselbe steht in der Administration als Seiten vorladen zur Verfügung (Caches vorwärmen).

Checkliste #

• To do: View-Caching, Template-Kompilierung und der Template-Cache sind in der Produktion eingeschaltet (keine Warnung unter Setup > Systeminformationen).
• To do: Das Team weiß, welcher Cache bei welcher Änderung zu leeren ist, und nutzt zuerst --dry-run.
• To do: Seiten-Caches werden nach dem Neuladen des Codes geleert, nicht davor (der Deploy-Befehl erledigt das).
• To do: Die Website wird nach einem vollständigen Leeren oder einem Deployment vorgewärmt.
• To do: Die Kapazität ist für angemeldeten Verkehr geplant, der gerendert und nicht aus dem Antwortcache bedient wird.

Verwandte Seiten #

• Statischer Cache und Antwortcache
• Lastspitzen planen
• Leistung und Caching für Websites
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.