Persistenten Object Cache gezielt einsetzen

Cookbook: Ziel und Ergebnis

Redis oder Memcached soll wiederholte WordPress-Objekte über PHP-Anfragen hinweg halten. Der Nutzen wird an dynamischen Pfaden gemessen, nicht an Page-Cache-Hits.

Rezept: Schritt für Schritt

1. Dynamische Baseline für Admin, eingeloggte Seite, Suche und Checkout erfassen: TTFB, Query-Zahl, Query-Zeit und P95.
2. Vom Host bereitgestellten Dienst, PHP-Erweiterung und ein kompatibles object-cache.php-Drop-in verwenden; eindeutiges Key-Präfix setzen.
3. RAM-Limit und Eviction-Strategie festlegen. Nie mehrere WordPress-Installationen ungetrennt denselben Namespace nutzen lassen.
4. Aktivieren, Cache einmal füllen und unter gleicher Last Hit-Rate, Speicher, Evictions und Fehlverhalten messen.

Rechenweg oder Entscheidungsregel

Cache-Nutzen (%) = (DB-Zeit vorher − DB-Zeit nachher) / DB-Zeit vorher × 100\nSpeicherreserve = Limit − used_memory\nEviction-Rate = evicted_keys / Messdauer

Eine gute Hit-Rate allein genügt nicht: permanent steigende Evictions oder Netzwerklatenz können den Nutzen aufzehren.

Praxisbeispiel

Checkout-P95 sinkt von 1,4 auf 1,0 s und DB-Zeit von 420 auf 160 ms; Redis nutzt 320 von 512 MB ohne Evictions. Das ist ein belastbarer Gewinn. Bei einer statischen Seite mit 99 % Full-Page-Hits kann derselbe Cache kaum messbar sein.

Prüfen, ob es funktioniert

• Keine Evictions im normalen Betrieb und ausreichend Speicherreserve.
• Bei Redis-Ausfall bleibt die Site funktional oder fällt kontrolliert zurück.
• Cache-Gruppen invalidieren nach Produkt-, Benutzer- und Optionsänderungen korrekt.

Rollback

Object-Cache über die vorgesehene Integration deaktivieren, Drop-in nur über deren Deinstallationsweg entfernen und PHP-/Page-Cache kontrolliert leeren. Präfix und Zugangsdaten dokumentiert lassen; Dienst nicht löschen, wenn andere Sites ihn nutzen.

Wann er hilft

Ein persistenter Object Cache bewahrt WordPress-Objekte über einzelne PHP-Anfragen hinweg. Das ist besonders wertvoll bei eingeloggten Nutzern, Shops, komplexen Queries und vielen dynamischen Seiten. Bei anonymen, vollständig seitengecacheten Aufrufen wird WordPress häufig gar nicht gestartet; dort ist der Zusatznutzen klein.

Voraussetzungen

Ein Redis-/Memcached-Dienst allein reicht nicht. WordPress benötigt ein kompatibles object-cache.php-Drop-in, die passende PHP-Erweiterung, Speichergrenzen und Eviction-Monitoring. In Shared Hosting darf nur die vom Host freigegebene Verbindung genutzt werden.

Risiken

Falsche Präfixe können Installationen vermischen. Zu wenig Speicher erzeugt ständige Verdrängung; ein nicht erreichbarer Cache kann Anfragen verzögern. Plugins müssen korrekt invalidieren. Verwende keinen dateibasierten „Object Cache“ als vermeintlichen Redis-Ersatz ohne Messung.

Erfolgskontrolle

Vergleiche dynamische Serverzeit und Datenbankabfragen vor/nach Aktivierung. Beobachte Hit-Rate, belegten Speicher, Evictions und Fehler. Page-Cache-Hits sind für diesen Vergleich ungeeignet.

Quellen und Prüfstand

• WordPress: Object Cache im Cache-Handbuch
• LiteSpeed: Object Cache

Inhalt fachlich geprüft am 17. August 2026. Konkrete Werte sind Ausgangspunkte, keine Universaldosierung.