Plugin Object Cache Pro - 1.26.0

Object Cache Pro ist ein persistentes Objekt-Cache-Backend für WordPress auf Basis von Redis – es entlastet MySQL genau dort, wo der Seiten-Cache nicht hinreicht. Es bewährt sich in WooCommerce-Shops und Multisite-Netzwerken, in denen Batch-Prefetching und Datenkompression die Kosten der Redis-Operationen senken.

Objekt-Cache in Redis und Seiten-Cache — was Object Cache Pro beschleunigt

Object Cache Pro speichert in Redis die Ergebnisse von Datenbankabfragen, WordPress-Optionen, Metadaten und Transients. Beim nächsten HTTP-Request kommen dieselben Daten aus dem Arbeitsspeicher – ohne erneute Abfrage von MySQL. Das ist eine Ergänzung zum Seiten-Cache, kein Ersatz dafür – es wirkt dort, wo statisches HTML nicht ausreicht: Warenkorb, Kasse, Administrationsbereich, Seiten für angemeldete Benutzer.

Warum der eingebaute Objekt-Cache von WordPress nicht ausreicht

Der Standard-Objekt-Cache von WordPress ist nicht persistent – er hält Daten nur für die Dauer eines einzelnen HTTP-Requests vor. Ist der Request beendet, verschwindet der Speicherinhalt. Beim nächsten Aufruf fragt WordPress dieselben Optionen, Metadaten und Transients erneut aus der Datenbank ab.

Object Cache Pro ersetzt diese nicht persistente Schicht durch die Drop-in-Datei object-cache.php, die WordPress mit Redis verbindet. Beim ersten Request gespeicherte Daten bleiben im Arbeitsspeicher erhalten und stehen bei jedem weiteren Aufruf zur Verfügung – ohne wiederholte SQL-Abfragen.

Warenkorb, Kasse und Administrationsbereich — wo der Seiten-Cache nicht greift

Der Seiten-Cache erzeugt statisches HTML und liefert es an anonyme Besucher aus. Warenkorb, Kasse, Kundenkonto, Administrationsbereich, Ergebnisse der Produktfilterung – diese Seiten sind von diesem Mechanismus ausgenommen. Ihr Inhalt ändert sich bei jedem Request abhängig von der Benutzersitzung.

Jedes Laden dieser Seiten erzeugt Abfragen an MySQL. Der Objekt-Cache – die einzige Cache-Schicht, die diese Last verringert – hält wiederkehrende Daten im Redis-Speicher vor.

Was Object Cache Pro nicht macht (keine Minifizierung, Bilder oder CDN)

Object Cache Pro arbeitet ausschließlich auf der Datenebene. Es erzeugt kein statisches HTML, minifiziert weder CSS noch JavaScript, optimiert keine Bilder und verwaltet kein CDN. Es ist ein einzelner Baustein im Performance-Stack – es ergänzt WP Rocket, LiteSpeed Cache oder Batcache, ersetzt sie aber nicht.

Prefetching, Datenkompression und binäre Serialisierung

Object Cache Pro senkt die Kosten der Redis-Operationen mit drei Mechanismen: Batch-Prefetching holt Cache-Schlüssel gesammelt ab – in einem einzigen Paket pro Gruppe statt Dutzender einzelner Abfragen; die Komprimierung mit den Algorithmen lzf, lz4 oder zstd verringert das Datenvolumen; der Serializer igbinary speichert PHP-Strukturen in kompakter Binärform. Laut Hersteller sinkt der Speicherverbrauch von Redis dadurch um 70–80 %.

Batch-Prefetching von Cache-Schlüsseln

Das Plugin merkt sich, welche Schlüssel eine bestimmte Seite zuvor abgerufen hat, und holt sie beim nächsten Aufruf mit einer einzigen Abfrage aus Redis – die ganze Gruppe auf einmal. Die Liste der vorab geladenen Schlüssel wird bei jedem Request aktualisiert und passt sich so an eine sich ändernde Seitenstruktur an.

Der Mechanismus ist standardmäßig deaktiviert – er muss in der Konfiguration manuell aktiviert werden. Gruppen, die Probleme verursachen, lassen sich über die Option non_prefetchable_groups ausschließen.

Kompression mit lz4 und zstd sowie der Serializer igbinary

Zur Komprimierung der zwischen WordPress und Redis übertragenen Daten stehen drei Algorithmen zur Verfügung: lzf, lz4 und zstd. Die Wahl hängt von der Priorität ab – lz4 minimiert die Leselatenz, zstd setzt auf eine geringe Datengröße.

Der Serializer igbinary ersetzt die Standard-Serialisierung von PHP durch eine kompakte Binärform – laut Hersteller sinkt die durchschnittliche Datengröße dadurch um etwa 50 %. Er erfordert die PHP-Erweiterung igbinary sowie eine Kompilierung von PhpRedis mit dem Flag –enable-redis-igbinary.

Hinweis: Ein Wechsel des Serializers oder des Komprimierungsalgorithmus auf einer laufenden Installation erfordert vorher das vollständige Leeren der Redis-Datenbank – andernfalls drohen Datenbeschädigungen.

Asynchrones und atomares Leeren von Cache-Gruppen

Die Option async_flush verlagert das Löschen großer Schlüsselmengen in einen Hintergrundprozess von Redis (Redis 4.0+) – der Löschvorgang blockiert dabei keine anderen Abfragen. Hinweis: Dragonfly unterstützt async_flush nicht.

Zweig 2.0 führt das atomare Leeren von Gruppen ein (group_flush => atomic) – Cache-Gruppen landen in Redis-Hashes mit Feld-Ablaufzeiten, und der Aufruf von wp_cache_flush_group() leert genau eine Gruppe, ohne Schlüssel nach einem Muster zu durchsuchen. Voraussetzungen: Redis 8.0 oder Valkey 9.0 sowie PhpRedis 6.3 oder Relay 0.12.1.

Kontrolle der Schlüssel-Lebensdauer und Aufteilung von alloptions

Die Option maxttl erzwingt eine maximale Lebensdauer für alle neuen Cache-Schlüssel – veraltete Daten bleiben so nicht unbegrenzt in Redis liegen. Eine separate Option, queryttl (standardmäßig 24 Stunden), steuert das Ablaufen von Schlüsseln in den *-queries-Gruppen. Das Plugin räumt einmal pro Stunde automatisch abgelaufene Abfrage-Schlüssel auf.

Der Mechanismus split_alloptions speichert jede automatisch geladene Option in einem eigenen Hash-Feld, statt alle in einem einzigen Schlüssel zu bündeln. Der Effekt: ein geringeres Risiko von Race Conditions bei gleichzeitigen Schreibvorgängen und – bei Relay – reduzierte Invalidierungen des gemeinsam genutzten Speichers.

Cache-Analyse, Flush-Protokoll und WP-CLI-Befehle

Object Cache Pro zeigt im WordPress-Dashboard Diagramme zu Treffern, Fehlschlägen, Latenzen und dem Speicherverbrauch von Redis. Das Flush-Protokoll erfasst die letzten Leerungen und versucht zu ermitteln, welches Plugin oder welche Funktion sie ausgelöst hat. Über die Konsole stehen gut ein Dutzend wp-redis-Befehle zur Verfügung – von status und diagnostics über flush und flush-group bis hin zu slowlog, groups und prune-queries.

Diagramme zu Treffern, Fehlschlägen und Latenzen im WordPress-Dashboard

Der Bereich Settings > Object Cache im Administrationsbereich enthält interaktive Diagramme: Cache-Treffer und -Fehlschläge, Latenzen, Speicherverbrauch von Redis. Ein Widget im Dashboard zeigt den Verbindungsstatus – mit einem Klick aktiviert es das Drop-in oder leert den Cache.

Die Datenaufbewahrung (standardmäßig 2 Stunden), der Prozentsatz der gemessenen Requests (sample_rate) und die Option footnote – ein HTML-Kommentar mit Metriken am Ende jeder Seite – sind konfigurierbar.

Flush-Protokoll — welches Plugin den Cache leert

Das Plugin speichert die letzten 10 Cache-Leerungen (das Limit lässt sich per Filter ändern) und versucht zu ermitteln, welches Plugin oder welche Funktion den Flush ausgelöst hat. Bei Installationen mit mehreren Dutzend aktiven Plugins ist das ein Werkzeug, um einem sinkenden Hit-Ratio auf die Spur zu kommen.

Der Filter pre_objectcache_flush erlaubt es, per Code Flushes zu blockieren, die von einem bestimmten Plugin ausgelöst werden – ohne dessen Code zu verändern.

wp-redis-Befehle, REST API und PSR-3-Logging

Über WP CLI stehen unter anderem folgende Befehle zur Verfügung:

• wp redis status – Zusammenfassung von Verbindungsstatus, Treffern und Speicher.
• wp redis diagnostics – vollständiger Diagnosebericht.
• wp redis flush / flush-group – Leeren des gesamten Caches oder einer ausgewählten Gruppe, mit der Möglichkeit, eine Website im Multisite-Netzwerk anzugeben.
• wp redis groups – Scan der Cache-Gruppen mit Schlüsselanzahl und optionaler Anzeige des Speicherverbrauchs.
• wp redis slowlog / commands – Protokoll langsamer Operationen und Statistiken zu Redis-Befehlen.

Die REST API unter dem Endpunkt /objectcache/v1/ stellt Analysedaten, Cache-Gruppen und Plugin-Optionen bereit. Das Plugin protokolliert Ereignisse über die PSR-3-Schnittstelle – standardmäßig gehen Fehler an stderr, und bei aktiviertem WP_DEBUG wird der interne ArrayLogger aktiv.

Redis-Cluster, Sentinel und TLS-Verbindungen

Object Cache Pro verbindet sich mit einer einzelnen Redis-Instanz, mit einem Redis-Cluster, mit einem Sentinel-Verbund und mit Primary-Replica-Replikation. Es unterstützt verschlüsselte TLS-Verbindungen, Authentifizierung über ACLs ab Redis 6 und Unix-Sockets. Die Konfiguration befindet sich in der Konstante WP_REDIS_CONFIG in der wp-config.php – rund 50 Optionen, jede davon auch als Umgebungsvariable verfügbar.

Redis, Valkey, KeyDB und Dragonfly

Object Cache Pro arbeitet mit Redis und drei Forks zusammen: Valkey, KeyDB und Dragonfly. Die Kompatibilität mit KeyDB wurde in Version 1.25.0 verbessert. Die einzige bekannte Einschränkung betrifft Dragonfly – dort fehlt die Unterstützung für das asynchrone Leeren von Schlüsseln (async_flush).

Cluster, Replicas und Failover-Strategien

Der Redis-Cluster wird über ein Array von Knoten und eine Failover-Strategie konfiguriert (none, error, distribute, distribute_replicas). Redis Sentinel erkennt den aktuellen Primary und die Replicas automatisch, sobald die Liste der Sentinels und der Dienstname angegeben sind. Die Primary-Replica-Replikation verteilt Lesevorgänge mit den Strategien distribute, distribute_replicas und concentrate auf die Replicas.

Das Plugin arbeitet mit AWS ElastiCache zusammen, auch mit der Serverless-Variante. Relay 0.22+ ergänzt Cluster-Optionen: cluster_az (Anbindung von Lesevorgängen an eine Verfügbarkeitszone), cluster_distribution_strategy und cluster_failover_strategy.

Konfiguration in der wp-config.php, über Umgebungsvariablen und als Must-Use-Plugin

Die Konstante WP_REDIS_CONFIG in der wp-config.php ist der einzige Ort zur Konfiguration der Verbindung – der Einstellungsbildschirm im Administrationsbereich dient der Analyse und den Werkzeugen, nicht der Konfiguration von Host, Port oder Passwort. Jede Option lässt sich auch als Umgebungsvariable angeben, was zu containerisierten und skriptbasierten Deployments passt.

Object Cache Pro funktioniert auch als Must-Use-Plugin, auch mit einem Verzeichnis außerhalb des Web-Roots (Konstante WP_REDIS_DIR). Die Installation über Composer wird nativ unterstützt – ein fertiges post-update-cmd-Skript aktualisiert das Drop-in automatisch.

Für welche Websites Object Cache Pro sinnvoll ist

Object Cache Pro entfaltet seine Wirkung vor allem in WooCommerce-Shops mit großem Produktkatalog, in Portalen und Mitgliederbereichen mit viel Traffic angemeldeter Benutzer sowie in Multisite-Netzwerken, wo jede Cache-Leerung mehrere Websites gleichzeitig betrifft. Auf kleinen Visitenkarten-Websites mit funktionierendem Seiten-Cache fällt der Unterschied oft kaum ins Gewicht – dort erfüllt ein kostenloses Objekt-Cache-Plugin dieselbe Aufgabe.

WooCommerce-Shops mit großem Katalog und Traffic-Spitzen

Warenkorb, Kasse, Kundenkonto und Filterergebnisse werden außerhalb des Seiten-Caches gerendert – jeder solche Aufruf wird direkt von der Datenbank bedient. Bei einem Shop mit mehreren Tausend Produkten und Traffic-Spitzen während Kampagnen übernimmt der Objekt-Cache die wiederkehrenden Abfragen nach Optionen, Produkt-Metadaten und Archivergebnissen.

Der Hersteller gibt an, Object Cache Pro mit WooCommerce zu testen. Cache-Gruppen, die Probleme verursachen (z. B. wc_session_id), lassen sich von der Persistenz ausschließen, und die fertige Konfiguration „High Performance“ kombiniert lz4, igbinary, Prefetch und reduzierte Timeouts.

Portale und Dienste mit vielen angemeldeten Benutzern

Überall dort, wo Inhalte personalisiert sind – Benutzerbereiche, Kurssysteme, interne Werkzeuge – kommt der Seiten-Cache nicht zum Einsatz, weil jede Ansicht von der Sitzung abhängt. Der Objekt-Cache ist in einem solchen Szenario die einzige Schicht, die die Zahl der Datenbankabfragen verringert.

Multisite-Netzwerke und mehrere Websites auf einer Redis-Instanz

Standardmäßig leert wp_cache_flush() in WordPress die gesamte Redis-Datenbank – bei einem Multisite-Netzwerk löscht eine Website damit den Cache aller anderen mit. Object Cache Pro löst das mit der Option network_flush: Im Modus site betrifft die Leerung nur die Schlüssel der jeweiligen Website, im Modus global werden zusätzlich die globalen Gruppen (users, usermeta) geleert. Unter Network Admin > Sites erscheint pro Website eine Aktion „Flush“.

Bei mehreren unabhängigen WordPress-Installationen auf einem gemeinsamen Redis-Server empfiehlt der Hersteller, jeder einen eigenen Datenbankindex zuzuweisen (Parameter database). Redis Cluster unterstützt keine mehreren Datenbanken – dort erhält jede Website ein eindeutiges Präfix.

Wann Object Cache Pro nicht benötigt wird

Für wen Object Cache Pro nicht notwendig ist:

• Websites auf Shared Hosting ohne Redis und ohne die PhpRedis-Erweiterung – das Produkt enthält weder einen Redis-Server noch liefert es die Erweiterung mit.
• Kleine Visitenkarten-Websites und Blogs mit geringem Traffic – bei funktionierendem Seiten-Cache fällt der Gewinn durch den Objekt-Cache oft kaum ins Gewicht.
• Wer ein einzelnes Werkzeug für die gesamte Optimierung sucht – Object Cache Pro erledigt weder Seiten-Cache noch Minifizierung, Bildoptimierung oder CDN.
• Benutzer ohne Zugriff auf die wp-config.php und die Konsole – die Konfiguration erfolgt ausschließlich über eine PHP-Konstante.
• Kunden von Hosting-Anbietern, bei denen das Plugin bereits anbieterseitig bereitgestellt wird (Nexcess, Cloudways, Rocket.net, Pantheon) – die Verfügbarkeit sollte vor dem Kauf beim Anbieter geprüft werden.

Integrationen mit WooCommerce, Query Monitor, Relay und APM-Werkzeugen

Object Cache Pro wird mit WooCommerce getestet, ergänzt Query Monitor um ein eigenes Diagnose-Panel und arbeitet mit Relay zusammen – einer PHP-Erweiterung, die einen Teil der Redis-Daten im gemeinsam genutzten Prozessspeicher vorhält. Cache-Metriken gelangen über den integrierten Tracer zu New Relic oder – über OpenTelemetry – zu Datadog, Blackfire oder Scout APM.

WooCommerce, Jetpack und Yoast SEO

Der Hersteller gibt an, Object Cache Pro für WooCommerce zu testen und zu optimieren – dabei werden der Code und kommende WooCommerce-Releases auf Cache-Probleme hin beobachtet. Jetpack und Yoast SEO sind weitere Plugins, für die Object Cache Pro optimiert ist.

Object Cache Pro arbeitet mit Seiten-Cache-Plugins (Batcache, WP Rocket) als ergänzende Schicht zusammen – der Objekt-Cache übernimmt die Daten in der Datenbank, der Seiten-Cache liefert statisches HTML aus.

Query Monitor und die Anzeige von Redis-Befehlen

Die Integration mit Query Monitor umfasst ein eigenes Panel mit Treffern, Fehlschlägen und Cache-Gruppen. Bei aktivierter Option save_commands zeigt das Panel alle während eines Requests ausgeführten Redis-Befehle an – zusammen mit der Information, welcher Teil des Codes sie ausgelöst hat. Die Kompatibilität mit Query Monitor 4.x wurde in Version 1.25.3 behoben.

Relay als Schicht im PHP-Speicher

Relay ist eine PHP-Erweiterung, die eine teilweise Kopie der Redis-Daten im gemeinsam genutzten Speicher des PHP-Prozesses vorhält. Nach der Umstellung der Option client auf Relay sinken Lesevorgänge unter eine Millisekunde – die Daten kommen aus dem lokalen Speicher, ohne Netzwerkkommunikation mit dem Redis-Server.

Ab Version 1.24.0 ist die experimentelle Unterstützung für den Adaptive Cache von Relay verfügbar. Die Cluster-Optionen von Relay (cluster_az, cluster_distribution_strategy) erfordern Relay 0.22.0 oder neuer.

New Relic, OpenTelemetry und Seiten-Cache-Plugins

Der integrierte New-Relic-Tracer aktiviert sich automatisch, sobald die Erweiterung erkannt wird. Der open-telemetry-Tracer (erfordert das Paket open-telemetry/api) öffnet die Integration mit Datadog APM, Blackfire und Scout APM.

Object Cache Pro arbeitet mit Seiten-Cache-Plugins (WP Rocket, LiteSpeed Cache, Batcache) konfliktfrei zusammen – beide Schichten arbeiten unabhängig voneinander und decken unterschiedliche Phasen der Request-Verarbeitung ab.

Voraussetzungen: Redis-Server, PhpRedis und PHP-Versionen

Object Cache Pro benötigt einen laufenden Redis-Server (oder Valkey, KeyDB bzw. Dragonfly) sowie die PHP-Erweiterung PhpRedis ab Version 4.0 – keines dieser Elemente liefert das Plugin in seinem Paket mit. Die minimal unterstützte PHP-Version ist 7.2. Der Hersteller testet das Plugin im gesamten Bereich PHP 7.2–8.6 sowie Redis 4.0–8.8, sowohl bei einzelnen Instanzen als auch in Clustern.

Die Erweiterung PhpRedis und die fehlende Unterstützung für Predis

PhpRedis ist die einzige erforderliche PHP-Erweiterung – sie muss sowohl für PHP-FPM als auch für die CLI (wp-redis-Befehle) installiert sein. Die Mindestversion ist 4.0, Zweig 2.0 erfordert 5.0 oder neuer.

Predis – ein rein in PHP geschriebener Redis-Client, der keine PECL-Erweiterung benötigt – wird von Object Cache Pro nicht unterstützt, obwohl derselbe Autor die Predis-Bibliothek pflegt. Der Hersteller begründet dies mit der Performance: Die native C-Erweiterung ist schneller als ein in PHP geschriebener Client.

Konfiguration des Redis-Servers: Speicher-Verdrängungsrichtlinie (maxmemory-policy)

Hinweis: Für den Redis-Server muss eine Speicher-Verdrängungsrichtlinie festgelegt sein (maxmemory-policy, z. B. allkeys-lru oder allkeys-lfu). Ohne sie nimmt Redis nach Erschöpfung des zugewiesenen Speichers keine Schreibvorgänge mehr an, was zu Fehlern im Betrieb von WordPress führt. Alternativ verhindert ein kurzer maxttl-Wert in der Plugin-Konfiguration, dass Schlüssel unbegrenzt liegen bleiben.

Verfügbarkeit von Redis bei Hosting-Anbietern

Object Cache Pro benötigt einen Redis-Server auf Seiten des Hosting-Anbieters.

Redis ist teils erst in höheren Hosting-Paketen oder auf VPS-Servern verfügbar.

Häufig gestellte Fragen