Redis kann Datenbankarbeit reduzieren, ist aber nicht automatisch ein Vorteil. Netzwerk-Latenz, Eviction, Serialisierung und Plugin-Verhalten können selbst zum Engpass werden.
„Verbunden“ beweist keinen gesunden Object Cache. Hit Rate, Latenz, Speicherdruck und reales Anwendungsverhalten messen.
1. Prüfen, wo Redis läuft
Lokaler Socket, lokales TCP und Remote Redis haben sehr unterschiedliche Latenz. Ein entfernter Cache kann langsamer sein als die ersetzten DB-Abfragen.
2. Speicher und Eviction Policy prüfen
Häufige Evictions erzeugen ungleichmäßige Performance und entfernen Objekte, bevor sie Nutzen bringen.
3. Stale Data von Page Cache trennen
Object Cache, Full-Page-Cache und CDN speichern unterschiedliche Dinge. Die Ebene leeren, die den veralteten Wert tatsächlich besitzt.
4. Große oder stark wechselnde Objekte suchen
Große Options, Transients und schnell wechselnde Keys erhöhen Speicher- und Serialisierungskosten.
5. wp-admin separat messen
Backend-Ansichten zeigen Object-Cache-Probleme oft deutlicher als anonyme Frontend-Benchmarks.
6. Mit und ohne Redis vergleichen
Kontrolliertes A/B-Messen ist besser als Annahmen. Wird der Zielpfad ohne Object Cache schneller, zuerst die Ursache untersuchen.