Varnish vor dem Cluster: eine eigene Caching-Schicht statt Anwendungs-Caching
Eine Entscheidung, die vor der Anwendung fällt
Caching lässt sich an zwei Stellen lösen: im Anwendungscode selbst, etwa über einen Cache innerhalb von TYPO3, oder davor, auf einer eigenen Schicht, die eine Anfrage beantwortet, bevor sie die Anwendung überhaupt erreicht. Ein dedizierter Edge-Cache wie Varnish verfolgt den zweiten Weg: er spricht reines HTTP, kennt die Anwendung dahinter nicht und liefert eine zwischengespeicherte Antwort allein auf Basis der Anfrage und ihrer Header. Das macht ihn schnell, aber auch blind gegenüber allem, was nicht im HTTP-Protokoll steht.
Drei Wege, einen Cache-Eintrag zu entfernen
Veraltete Inhalte müssen aus dem Cache verschwinden, und dafür gibt es unterschiedliche Werkzeuge, je nachdem wie genau das Ziel beschrieben werden kann. PURGE verwirft einen einzelnen, exakt adressierten Eintrag. Das reicht, solange ein Inhalt nur unter einer URL existiert. Erscheint derselbe Inhalt dagegen unter mehreren URLs, etwa einer Übersichts- und einer Detailansicht, stößt PURGE an seine Grenze. BAN löst das anders: es markiert alles, was einem Muster entspricht, als veraltet und erzwingt beim nächsten Zugriff einen frischen Abruf, unabhängig davon, wie viele URLs betroffen sind.
Der Zustand, den man leicht übersieht
Nicht jede Antwort ist cachebar, und Varnish merkt sich diese Entscheidung selbst: Trägt eine Antwort Set-Cookie, ein Cache-Control: no-store oder private, oder eine Gültigkeitsdauer von null, geht Varnish in einen Zustand, der "hit-for-miss" genannt wird. Jede weitere Anfrage auf dieselbe URL geht für eine gewisse Zeit direkt ans Backend durch, ohne dass der Cache es noch einmal versucht. Praktisch bedeutet das: trifft viel gleichzeitiger Traffic auf eine solche Seite, erreicht jede einzelne Anfrage das Backend, nicht nur die erste. Wer Cache-Verhalten allein an der Trefferquote ablesen will, ohne diesen Zustand zu kennen, zieht leicht falsche Schlüsse.
Was dafür korrekt gesetzt sein muss
Ein Edge-Cache funktioniert nur, sofern die Anwendung die richtigen Signale sendet. Cache-Control-Header entscheiden, wie lange ein Inhalt gültig ist, Vary-Header, welche Variante zu welcher Anfrage gehört. Fehlen diese Angaben oder sind sie falsch gesetzt, liefert der Cache entweder veraltete Inhalte aus oder cacht überhaupt nichts, ohne dass das auf den ersten Blick auffällt. Die Verantwortung liegt damit nicht allein beim Cache, sondern genauso bei der Anwendung dahinter.
Warum diese Schicht beim TYPO3-Betrieb eine eigene Disziplin ist
Caching als eigene, vom TYPO3-Anwendungscode unabhängige Schicht zu betreiben, ist eine Architektur-Entscheidung, keine Konfigurations-Kleinigkeit: Invalidierung, Header-Korrektheit und das Verhalten bei nicht-cachebaren Antworten wie Formularseiten müssen bewusst verwaltet werden, nicht der Anwendung allein überlassen.
Quellen: Varnish-Dokumentation zur Cache-Invalidierung, Varnish-Guide zur Trefferquote.
