WordPress Object Cache Hit Rate: Aussagekraft und sinnvolle Zielwerte

Was der WordPress Object Cache speichert

Der WordPress Object Cache hält Daten unter einem Schlüssel und innerhalb einer Gruppe bereit. Fragt WordPress denselben Wert erneut ab, kann es ihn aus dem Cache beziehen, statt die zugrunde liegende Arbeit erneut auszuführen. Dazu gehören beispielsweise Daten, die sonst aus der Datenbank gelesen oder erneut berechnet werden müssten.

Die eingebaute Core-Implementierung ist standardmäßig requestgebunden: Sie hält ihre Einträge während eines einzelnen Requests vor. Ein späterer Seitenaufruf erhält dadurch nicht automatisch Zugriff auf die zuvor gespeicherten Werte. Trotzdem kann der Cache schon innerhalb eines Requests wiederholte Zugriffe vermeiden.

Ein Drop-in kann die Core-Implementierung durch einen persistenten Object Cache ersetzen. Dann können geeignete Einträge über einzelne Requests hinaus erhalten bleiben. Redis ist eine mögliche Backend-Option, aber keine Voraussetzung für WordPress; auch andere Backend-Ansätze sind möglich. Selbst mit einem persistenten Drop-in können bestimmte Gruppen weiterhin nur für den aktuellen Request gelten.

Transients sind eine weitere Möglichkeit, zeitlich begrenzt benötigte Daten abzulegen. Mit einem persistenten Object Cache können sie dort gespeichert werden, ohne ihn normalerweise in der Datenbank. Ihre Ablaufzeit bezeichnet keine garantierte Mindestverfügbarkeit: Ein Wert kann früher verschwinden. Anwendungscode muss deshalb mit einem fehlenden Transient rechnen und den Wert bei Bedarf regenerieren können.

Für die spätere Bewertung einer Trefferquote ist diese Unterscheidung entscheidend: Ein Zugriff auf den lokalen Cache während eines Requests und ein Zugriff auf ein externes Backend sind nicht zwangsläufig dieselbe Messgröße. Prüfe daher zunächst, welche Implementierung tatsächlich verwendet wird und welche Daten sie persistent behandelt.

Object Cache und Page Cache unterscheiden

Bei einem Seitenaufruf kann ein Page Cache eine bereits erzeugte Seitenantwort ausliefern. Wird die Anfrage dort beantwortet, muss sie nicht denselben WordPress-Anwendungspfad durchlaufen wie eine ungecachte Anfrage. Der Object Cache arbeitet dagegen innerhalb der Anwendung mit einzelnen zwischengespeicherten Daten, nicht mit der vollständigen Seitenantwort.

Stell dir eine öffentlich erreichbare Artikelseite vor: Liegt ihre Antwort im Page Cache, kann sie direkt ausgeliefert werden. Muss WordPress die Seite dagegen erzeugen, kann der Object Cache bei wiederholten Datenzugriffen helfen. Welche Arbeit dadurch tatsächlich entfällt, hängt von der Anfrage, den gespeicherten Einträgen und der jeweiligen Implementierung ab.

Das hat Folgen für die Interpretation: Eine gute Object-Cache-Quote beschreibt nur die erfassten Cache-Zugriffe. Sie sagt nicht unmittelbar, wie viele Besucher bereits eine fertige Antwort aus dem Page Cache erhalten oder wie schnell die gesamte Website reagiert. Bei starkem Page Caching kann der Nutzen des Object Cache vor allem bei den verbleibenden WordPress-Requests sichtbar werden.

Auch Browser- und Opcode-Cache erfüllen andere Aufgaben. Der Browser-Cache hält Ressourcen beim Besucher vor; ein PHP-Opcode-Cache speichert kompilierten PHP-Code. Beide ersetzen weder die Speicherung einzelner Anwendungsdaten im Object Cache noch die Auslieferung einer vollständigen Antwort aus einem Page Cache.

Die Konstante WP_CACHE allein aktiviert keinen Redis Object Cache. Für einen persistenten Object Cache brauchst du eine passende Implementierung und deren unterstützte Konfiguration. Ein ergänzendes Beispiel für das Zusammenspiel mehrerer Ebenen findest du im Beitrag zur AccelerateWP Cache Engine.

Was Hits und Misses aussagen

Ein Hit liegt vor, wenn ein gesuchter Eintrag auf der betrachteten Cache-Ebene gefunden wird. Ein Miss bedeutet, dass er dort nicht gefunden wird. Die Hit Rate setzt die Treffer ins Verhältnis zu allen gezählten Treffern und Fehlversuchen: Hits / (Hits + Misses) × 100. Gibt es weder Hits noch Misses, ist die Quote für diesen Zeitraum nicht definiert.

Ein Miss ist nicht automatisch ein technischer Fehler. Beim ersten Zugriff kann ein Eintrag noch fehlen; auch nach seinem Ablauf muss er gegebenenfalls neu beschafft oder erzeugt werden. Entscheidend ist, welche Folgen solche Fehlversuche im konkreten Ablauf haben und ob sich Zugriffe überhaupt sinnvoll wiederholen.

Die Core-Methode von WordPress zählt in ihrer eigenen Implementierung Cache-Treffer und Fehlversuche. Ein Drop-in kann diese Implementierung jedoch ersetzen. Deshalb lässt sich aus der Core-Zählweise nicht sicher ableiten, was eine Plugin-Anzeige erfasst: Prüfe für die eingesetzte Version, welche Zugriffe und welchen Zeitraum ihre Kennzahl umfasst.

Redis meldet mit keyspace_hits und keyspace_misses erfolgreiche beziehungsweise erfolglose Key-Lookups im Redis-Keyspace. Auch ein fehlgeschlagener EXISTS-Aufruf kann als Miss zählen. Diese Redis Hit Rate ist daher nicht automatisch mit einer WordPress- oder Plugin-Quote gleichzusetzen.

Kommt eine Redis-Instanz mehreren Websites oder Anwendungen zugute, können ihre Zähler deren Zugriffe gemeinsam abbilden. Eine globale Quote lässt sich dann ohne geeignete getrennte Telemetrie nicht belastbar einer einzelnen WordPress-Website zuordnen. Für jeden Vergleich solltest du deshalb festhalten, welche Ebene und welche Instanz die Zahlen überhaupt beschreiben.

Messbereich und Zugriff sicher prüfen

Kläre vor der Messung, welche Object-Cache-Implementierung WordPress verwendet. Wenn WP-CLI verfügbar ist und du Zugriff auf das WordPress-Verzeichnis hast, kannst du dort eine lesende Bestandsaufnahme mit folgendem Befehl beginnen:

wp cache type

Das Ergebnis hilft bei der Einordnung der Implementierung, beweist aber nicht, dass jeder relevante Zugriff persistent gespeichert wird. WordPress erlaubt einem Drop-in, den Core-Cache zu ersetzen; zugleich können einzelne Gruppen nicht persistent sein. Halte deshalb auch das eingesetzte Drop-in beziehungsweise Plugin und seine Version fest.

Prüfe in der Dokumentation der konkreten Version, welche Zugriffe ihre angezeigten Hits und Misses umfassen und über welchen Zeitraum sie gezählt werden. Eine Plugin-Quote lässt sich nur dann sinnvoll mit einer anderen Kennzahl vergleichen, wenn Messbereich und Zählweise bekannt sind. Besonders wichtig ist, ob die Anzeige nur einen Request oder ein längeres Fenster beschreibt.

Für Redis kannst du, sofern Verbindung und Berechtigungen vorhanden sind, in einer Redis-CLI-Sitzung die Statistik- und Speicherinformationen lesend abfragen. Die folgenden Befehle enthalten bewusst keine Zugangsdaten:

INFO stats
INFO memory

Dokumentiere den Messbereich: Welche Instanz oder Knoten wurden abgefragt, und welche anderen Websites oder Anwendungen nutzen sie? Globale Redis-Zähler lassen sich bei gemeinsamer Nutzung nicht ohne Weiteres einer einzelnen Website zuordnen. Prüfe Ausgaben vor der Weitergabe auf sensible Betriebsinformationen; weder ein Flush noch ein Lasttest ist für diese Bestandsaufnahme erforderlich.

Fehlt dir der Zugriff auf die Redis-CLI, frage deinen Hosting-Anbieter nach den verfügbaren Metriken und ihrem Geltungsbereich. Auch ein Dashboard ist nur dann eine brauchbare Grundlage, wenn klar ist, ob es dieselbe Instanz, einzelne Knoten oder bereits aggregierte Werte zeigt.

Redis Hit Rate im Intervall berechnen

Redis-Statistiken sind Zählerstände, keine fertige Aussage über einen bestimmten Messzeitraum. Lies für eine Intervallauswertung die Werte für keyspace_hits und keyspace_misses zu Beginn und am Ende desselben festgelegten Zeitfensters von derselben Instanz ab. Notiere beide Zeitpunkte und die zugehörige Instanz, damit die Ablesungen zusammenpassen.

Ziehe anschließend für jeden Zähler den Anfangswert vom Endwert ab. Die Intervall-Hit-Rate lautet: ΔHits / (ΔHits + ΔMisses) × 100. Das Zeichen Δ steht für die jeweilige Differenz. Sind beide Differenzen null, gab es in diesem Fenster keine gezählten Lookups; die Quote ist dann nicht definiert, statt null Prozent zu betragen.

Ein illustratives Rechenbeispiel, keine Messung: Steigen die Hits um 900 und die Misses um 100, ergeben sich 90 Prozent bei insgesamt 1.000 gezählten Lookups. Das heißt weder, dass Seiten um 90 Prozent schneller sind, noch dass genau 900 Datenbankabfragen eingespart wurden. Redis zählt Key-Lookups; deren Bedeutung für die Anwendung hängt vom jeweiligen Zugriff ab.

Geht einer der Zähler zwischen den Ablesungen zurück, ist die einfache Differenz über diesen Bruch nicht gültig. Ein Neustart oder das Zurücksetzen von Statistiken kann dazu führen. Beginne das Messfenster neu oder teile es anhand verlässlicher Betriebsdaten am Bruch auf, statt einen negativen Wert in die Formel einzusetzen.

Bei mehreren Knoten berechnest du zunächst für jeden passenden Knoten die Differenzen über denselben Zeitraum. Addiere dann die Hits und Misses getrennt und bilde daraus die Gesamtquote. Ein ungewichteter Mittelwert der einzelnen Prozentwerte behandelt einen Knoten mit wenigen Lookups sonst genauso wie einen mit vielen; das kann das Gesamtbild erheblich verzerren.

Halte dabei fest, welche Knoten tatsächlich einbezogen sind und welche Rolle sie in der Umgebung haben. Eine so berechnete Gesamtrate beschreibt nur die ausgewählten Zähler und deren Nutzer; sie wird nicht allein durch die Aggregation zu einer spezifischen WordPress-Object-Cache-Quote.

Messprotokoll und Redis-Kennzahlen

Neben Hits und Misses helfen weitere Redis-Zähler bei der Einordnung. Auch hier sind Differenzen im gewählten Zeitraum aussagekräftiger als isolierte Gesamtstände. Die folgende Tabelle trennt die Bedeutung der Werte von Schlussfolgerungen, die sie allein nicht tragen.

Ein Anstieg von expired_keys kann Anlass sein, Lebensdauern und Zugriffsmuster näher anzusehen. Er zeigt aber nicht, ob ein Eintrag kurz nach seinem Ablauf erneut benötigt wurde. Ebenso ist evicted_keys im Kontext der konfigurierten Speichergrenze und Verdrängungsstrategie zu betrachten, statt daraus sofort eine Speichererhöhung abzuleiten.

Ein brauchbares Messprotokoll nennt Anfang und Ende des Zeitfensters, Instanz beziehungsweise Knoten, die beiden Zählerdifferenzen, ihre Summe und die berechnete Quote. Ergänze, ob die Instanz gemeinsam genutzt wird und ob während des Fensters ein Neustart oder eine Rücksetzung bekannt ist. So bleiben Messungen später nachvollziehbar.

Erfasse parallel den betrachteten Request-Typ und eine dafür geeignete Latenzkennzahl sowie Datenbanklast und Fehlerrate. Trenne beispielsweise öffentliche Seitenaufrufe von eingeloggten Anfragen, wenn dafür passende Daten vorliegen. Die Redis-Quote allein verrät nicht, welcher dieser Request-Typen von einem Treffer profitiert hat.

Für einen späteren Vergleich sollten Zeitraum, Knoten und Request-Mischung möglichst ähnlich sein. Notiere außerdem relevante Änderungen und erkennbare Warm-up-Phasen. Wo Daten fehlen oder eine gemeinsame Instanz keine Zuordnung erlaubt, gehört diese Einschränkung ins Protokoll statt in eine scheinbar präzise Schlussfolgerung.

Kaltstart, Shop und statische Website

Nach einem Neustart oder Deployment können benötigte Einträge zunächst fehlen. Solche Misses sind beim Befüllen des Cache zu erwarten; bei wiederkehrenden Zugriffen kann die Trefferquote anschließend steigen. Werte aus der Kalt- und Warmphase solltest du getrennt betrachten, damit ein langer Durchschnitt weder die Anlaufkosten noch das spätere Verhalten verdeckt.

Bei einem Shop oder einem eingeloggten Bereich sind dynamische Anfragen besonders interessant: Ein Page Cache beantwortet nicht unbedingt jeden Warenkorb- oder Kontoaufruf. Vergleiche deshalb möglichst ähnliche Request-Typen und achte neben der Quote auf ihre Antwortzeiten und die Datenbanklast. Eine hohe Redis Hit Rate zeigt für sich genommen nicht, ob der Warenkorb schnell und inhaltlich korrekt angezeigt wird.

Bei einer überwiegend statischen Website kann dagegen ein großer Teil der Seitenaufrufe bereits aus dem Page Cache kommen. Ein persistenter Object Cache wirkt dort vor allem auf die Anfragen, die WordPress tatsächlich verarbeitet. Beurteile deshalb getrennt, ob diese verbleibenden Anfragen profitieren und ob sich der Effekt auf die gesamte Website auswirkt.

Nutzt du Redis gemeinsam mit anderen Websites oder Anwendungen, umfassen die Instanzzähler deren Zugriffe ebenfalls. Ohne geeignete getrennte Telemetrie lässt sich die globale Quote keiner einzelnen Website zuverlässig zuordnen. Dokumentiere auch, welche Knoten erfasst sind: Eine Veränderung der Quote kann sonst ebenso an einer anderen Nutzung oder an einem veränderten Messbereich liegen.

Auffällige Werte und Fehler untersuchen

Eine niedrige Quote ist zunächst eine Beobachtung, keine Diagnose. Viele Erstzugriffe, kurze Lebensdauern oder eine Zugriffsverteilung mit selten wiederverwendeten Schlüsseln kommen als Erklärungen infrage. Prüfe, ob sich die Request-Mischung oder das Messfenster verändert hat, bevor du Speicher oder Cache-Einstellungen anpasst.

Die Zähler expired_keys und evicted_keys liefern weitere Hinweise: Der erste zählt abgelaufene Schlüssel, der zweite aufgrund der Speicherbegrenzung verdrängte Schlüssel. Ihre Differenzen gehören zur Redis-Instanz und müssen zur Konfiguration und Nutzung passen. Viele abgelaufene Schlüssel beweisen weder eine falsch gewählte TTL noch, dass eine längere Lebensdauer sinnvoll ist; sie kann die Aktualität gespeicherter Daten verschlechtern.

Für eigene Erweiterungen ist bei wp_cache_get der Parameter $found wichtig: Er unterscheidet einen gefundenen, gespeicherten Wert false von einem nicht gefundenen Eintrag. Vor gruppenbezogenen Aktionen solltest du mit wp_cache_supports prüfen, ob das konkrete Backend die gewünschte Funktion unterstützt. Ein ersetzendes Drop-in kann sich von der Core-Implementierung unterscheiden.

Warnung: Ein unbedachter Cache-Flush kann mehr Einträge oder Anwendungen betreffen als beabsichtigt und die nächste Messung durch einen Kaltstart verzerren. Kläre den Wirkungsbereich und eine Freigabe, bevor du löschende Aktionen ausführst. Ergänzende Ansatzpunkte zur Fehlersuche bei einem langsamen WordPress Object Cache helfen, auch möglichen Cache-Overhead in die Untersuchung einzubeziehen.

Sinnvolle Zielwerte selbst bestimmen

Eine universelle Mindestquote von 90 Prozent ist keine belastbare technische Anforderung. Sinnvoller ist ein standortspezifischer Zielbereich, der zur erwarteten Zugriffsverteilung und zum Nutzen für die Anwendung passt. Redis empfiehlt, die beobachtete Quote im Kontext des jeweiligen Zugriffsmusters zu beurteilen; ein Prozentwert allein erklärt noch keine WordPress Performance.

Erfasse zunächst eine repräsentative Ausgangsmessung mit Zeitraum, Messbereich, Zugriffszahl und Quote. Halte dazu Antwortzeiten wichtiger Request-Typen, Datenbanklast und Fehlerrate fest. Kennzeichne Kaltstarts gesondert und berücksichtige typische Unterschiede zwischen Zeiten mit wenig und viel Betrieb, statt ein zufällig günstiges Fenster als Normalzustand zu behandeln.

Plane anschließend eine konkrete Änderung und prüfe sie nach Freigabe möglichst zuerst in einer geeigneten Testumgebung. Stelle danach vergleichbare Zeiträume und Request-Mischungen gegenüber: Ändern sich Quote und Anzahl der Lookups, aber auch die Latenz oder die Datenbanklast? So lässt sich der Effekt besser von einer bloßen Verschiebung der Zugriffe unterscheiden.

Auch eine hohe Quote kann wenige, besonders teure Misses verdecken. Umgekehrt muss eine moderate Quote kein Problem sein, wenn relevante Anfragen schnell und korrekt beantwortet werden. Zusätzlicher Betriebsaufwand für Redis oder ein anderes persistentes Backend ist durch eine bessere Quote allein nicht automatisch gerechtfertigt; berücksichtige Hosting-Unterstützung, Kosten und mögliche Ausfallszenarien.