Redis-Objekt-Cache für WordPress auf einem VPS

Was ein Redis-Objekt-Cache für WordPress leistet

Ein Redis-Objekt-Cache für WordPress speichert die Ergebnisse von Datenbankabfragen im Arbeitsspeicher. Bei der nächsten Anfrage werden diese Ergebnisse aus Redis gelesen, statt MySQL erneut abzufragen. WordPress verfügt bereits über einen Objekt-Cache im Core, WP_Object_Cache. Dieser liegt jedoch im PHP-Arbeitsspeicher und wird verworfen, sobald die Anfrage endet. Eine Drop-in-Datei ersetzt ihn durch einen Cache, der mit Redis kommuniziert. Dadurch bleibt der Cache von einer Anfrage zur nächsten erhalten.

Objekt-Caching ist kein Seiten-Caching. Dieser Unterschied entscheidet, ob sich dieser Leitfaden für Sie lohnt. Ein Seiten-Cache speichert das fertige HTML einer URL und liefert es erneut aus, ohne PHP überhaupt auszuführen. Das ist schneller als alles, was Redis leisten kann, und funktioniert für nicht angemeldete Besucher. Sobald sich jemand anmeldet, einen Artikel in den Warenkorb legt oder den Administrationsbereich öffnet, tritt der Seiten-Cache zurück und WordPress verarbeitet die gesamte Anfrage: Bootstrap, Plugins und Abfragen. Ein Objekt-Cache macht genau diese Anfrage günstiger. Er ist für den Datenverkehr gedacht, den ein Seiten-Cache nicht abdecken kann: angemeldete Sitzungen, Warenkörbe, den Checkout und wp-admin. Bei einem WooCommerce-Shop betrifft das den größten Teil des aufwendigen Datenverkehrs.

Beide Verfahren ergänzen sich. Auf einer stark ausgelasteten Website gehören beide zur Konfiguration. Klären Sie, welches Problem Sie beheben. Eine Website mit statischen Informationen und anonymen Lesern bezieht fast ihren gesamten Geschwindigkeitsvorteil aus einem Seiten-Cache. Die zusätzliche Verwendung von Redis ändert dort nur wenig.

Bevor Sie beginnen, sollten Sie eine Einschränkung kennen. Ein Objekt-Cache macht eine langsame Abfrage nicht schneller. Er verhindert die Wiederholung einer Abfrage, die bereits ausgeführt wurde. Die erste Anfrage nach einem Cache-Miss zahlt weiterhin den vollen Preis. Ein Plugin, das eine nicht indexierte Abfrage ausführt, führt sie daher einmal pro Cache-Lebensdauer aus.

Was Sie zuerst benötigen

• Einen Linux-VPS mit Shell-Zugriff und sudo. Ein Control Panel ist nicht erforderlich.
• WordPress, das von PHP-FPM bereitgestellt wird, zum Beispiel ein LAMP-Stack unter Ubuntu 24.04.
• WP-CLI auf dem Server. Für jeden Schritt gibt es eine Entsprechung im Administrationsbereich. Die Shell-Variante ist jedoch schneller.
• Redis auf demselben Rechner wie PHP. Genau darauf kommt es bei der Latenz an. Ein Netzwerk-Hop macht diesen Vorteil zunichte.

Die folgenden Befehle gelten für Ubuntu 24.04 mit PHP 8.3 und dem Webbenutzer www-data. Passen Sie die PHP-Version und den Benutzer an Ihre Umgebung an. Führen Sie die wp-Befehle aus dem WordPress-Verzeichnis aus, das wp-config.php enthält.

Redis und die PHP-Erweiterung installieren

sudo apt update
sudo apt install -y redis-server php-redis
sudo systemctl enable --now redis-server
redis-cli ping

redis-cli ping sollte mit PONG antworten. Wenn Could not connect to Redis at 127.0.0.1:6379: Connection refused ausgegeben wird, läuft der Server nicht. Lesen Sie daher systemctl status redis-server, bevor Sie fortfahren.

php-redis ist PhpRedis, die C-Erweiterung von PECL. Sie ist schneller als Predis, das vollständig in PHP implementiert ist. Das Plugin verwendet PhpRedis automatisch, wenn die Erweiterung vorhanden ist. PHP-FPM lädt Erweiterungen beim Start. Eine neue Erweiterung ist daher erst nach einem Neustart des Pools verfügbar.

sudo systemctl restart php8.3-fpm
php -m | grep redis

Beachten Sie bei der letzten Prüfung: php -m listet die Module der PHP-Kommandozeile auf. FPM kann einen anderen Satz von Erweiterungen laden. Maßgeblich ist die eigene Diagnose des Plugins weiter unten.

Stand August 2026 enthält Ubuntu 24.04 Redis 7.0.15. Das ist für einen Objekt-Cache ausreichend. Wenn Sie stattdessen eine aktuelle Version verwenden möchten, stellt Redis ein eigenes APT-Repository bereit.

sudo apt install -y lsb-release curl gpg
curl -fsSL https://packages.redis.io/gpg | sudo gpg --dearmor -o /usr/share/keyrings/redis-archive-keyring.gpg
sudo chmod 644 /usr/share/keyrings/redis-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/redis-archive-keyring.gpg] https://packages.redis.io/deb $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/redis.list
sudo apt update
sudo apt install -y redis

Wenn Ihre Distribution Valkey bereitstellt, den nach der Lizenzänderung von 2024 gestarteten Fork, verwendet es dasselbe Protokoll. Alles Folgende gilt daher unverändert.

Redis so binden, dass kein anderer darauf zugreifen kann

Redis hat standardmäßig kein Passwort. Alles, was eine Verbindung zu Port 6379 öffnen kann, kann jeden zwischengespeicherten Wert lesen und FLUSHALL ausführen. Instanzen, die aus dem Internet erreichbar sind, werden innerhalb weniger Stunden von Scannern gefunden. Deshalb muss die Netzwerkkonfiguration vor dem Tuning erfolgen.

Öffnen Sie /etc/redis/redis.conf und prüfen Sie diese Zeilen:

bind 127.0.0.1 -::1
protected-mode yes

Prüfen Sie anschließend, worauf tatsächlich gelauscht wird. Die Konfigurationsdatei ist nur eine Vorgabe. ss liefert den Nachweis.

sudo ss -lntp | grep 6379

127.0.0.1:6379 ist der gewünschte Zustand. 0.0.0.0:6379 bedeutet, dass Redis auf der öffentlichen Schnittstelle antwortet. Korrigieren Sie die Zeile bind und starten Sie Redis neu.

Wenn PHP und Redis auf demselben System laufen, ist ein Unix-Socket besser als TCP über das Loopback-Interface. Dadurch befindet sich kein TCP-Stack im Kommunikationspfad. Der Zugriff wird über Dateiberechtigungen gesteuert und nicht über eine Firewall-Regel, die Sie später möglicherweise ändern.

unixsocket /run/redis/redis-server.sock
unixsocketperm 770

Der Socket gehört dem Benutzer und der Gruppe redis. Deshalb muss der Webbenutzer dieser Gruppe beitreten.

sudo systemctl restart redis-server
sudo usermod -aG redis www-data
sudo systemctl restart php8.3-fpm
redis-cli -s /run/redis/redis-server.sock ping

Auch dabei muss PONG ausgegeben werden. Could not connect to Redis at /run/redis/redis-server.sock: Permission denied bedeutet, dass die Gruppenmitgliedschaft nicht wirksam wurde. Prüfen Sie id www-data. Beachten Sie außerdem, dass ein laufender PHP-FPM-Prozess die Gruppen übernimmt, die beim Start gültig waren. Deshalb steht der Neustart in der Liste. Lassen Sie TCP aktiviert, bis der Socket nachweislich funktioniert. Andernfalls kann ein Tippfehler beide Zugriffswege gleichzeitig unbrauchbar machen.

Wie viel Arbeitsspeicher sollte Redis erhalten?

Leiten Sie den Wert aus Ihrem eigenen System ab. Redis ohne maxmemory wächst, bis der Kernel keinen Speicher mehr hat und der OOM-Killer einen Prozess beendet, normalerweise den größten. Auf einem WordPress-Server ist das häufig MySQL. journalctl -k | grep -i "out of memory" zeigt diesen Vorgang erst im Nachhinein. Zu diesem Zeitpunkt ist die Website bereits nicht erreichbar.

Beginnen Sie mit dem gesamten RAM und ziehen Sie die benötigten Werte ab. MySQL oder MariaDB reserviert innodb_buffer_pool_size sowie Puffer pro Verbindung. PHP-FPM benötigt pm.max_children multipliziert mit der tatsächlichen residenten Größe eines Workers. Auf einer Website mit vielen Plugins sind 64 MB bis 128 MB pro Worker üblich. Der Kernel und der Webserver benötigen einige hundert Megabyte. Der verbleibende Speicher ist Ihr Limit. Einen Teil davon erhält Redis.

Messen Sie jetzt, statt zu schätzen. Nach einem Tag mit echtem Datenverkehr:

redis-cli info memory | grep -E 'used_memory_human|maxmemory_human|maxmemory_policy'
redis-cli dbsize

Wenn used_memory_human deutlich unter Ihrem Limit bleibt, senken Sie das Limit und geben Sie den RAM an MySQL zurück. MySQL kann ihn besser nutzen. Wenn der Wert das Limit erreicht und evicted_keys den ganzen Tag steigt, erhöhen Sie das Limit. Setzen Sie den Wert in /etc/redis/redis.conf.

maxmemory 256mb
maxmemory-policy allkeys-lru

redis-cli config set maxmemory 256mb wird sofort angewendet und beim nächsten Neustart vergessen. Das ist dieselbe Falle wie bei einem einfachen sysctl -w. Bearbeiten Sie die Datei, führen Sie anschließend sudo systemctl restart redis-server aus und lesen Sie den Wert erneut aus. Eine zweite Begrenzung ist sinnvoll: ein MemoryMax-Limit für die systemd-Unit verhindert, dass ein falsch konfiguriertes Redis das System herunterfährt. Setzen Sie es oberhalb von maxmemory, niemals auf denselben Wert. Ein cgroup-Limit beendet den Prozess, statt einen Schlüssel aus Redis zu entfernen. Wenn Redis in einem Container neben WordPress läuft, gehört derselbe Wert in die Speicherlimits Ihrer Compose-Datei. Dieselbe Überlegung bestimmt die Wahl zwischen dem Betrieb der Datenbank in Docker oder auf dem Host.

Wählen Sie die Eviction-Richtlinie bewusst

Ein frisches Redis verwendet standardmäßig noeviction. Prüfen Sie Ihre Konfiguration:

redis-cli config get maxmemory-policy

Bei noeviction nimmt eine vollständig belegte Instanz keine Schreibvorgänge mehr an und antwortet mit Folgendem:

(error) OOM command not allowed when used memory > 'maxmemory'.

Diese einzelne Zeile beschreibt in diesem Leitfaden den schwerwiegendsten Fehlerzustand, weil die Website nicht ausfällt. Sie wird langsamer. Jeder Schreibvorgang in den Cache schlägt fehl. WordPress greift deshalb für den Wert wieder auf die Datenbank zu, versucht ihn bei der nächsten Anfrage erneut zu speichern und scheitert wieder. Die Website führt nun die gesamte ursprüngliche Datenbankarbeit aus und zusätzlich für jeden Schlüssel einen Roundtrip zu Redis. Im WordPress-Administrationsbereich wird dieser Zustand nicht angezeigt. Die Zeichenfolge erscheint im PHP-Fehlerprotokoll. Suchen Sie daher nach OOM command not allowed, wenn eine Website nach dem Hinzufügen eines Caches langsamer wird.

allkeys-lru ist hier die richtige Standardeinstellung. Redis verwirft bei knappem Speicher den am längsten nicht verwendeten Schlüssel. Genau das benötigt ein Object Cache, weil jeder darin gespeicherte Wert eine Kopie von Daten ist, die weiterhin in MySQL vorhanden sind. Der Verlust eines Schlüssels kostet eine Abfrage. Einen Schreibvorgang abzulehnen kostet dagegen jede Abfrage bei jeder Anfrage, bis jemand den Fehler bemerkt.

Vermeiden Sie für diese Aufgabe die Richtlinien volatile-*. Sie berücksichtigen nur Schlüssel mit einer Ablaufzeit. Redis dokumentiert, dass sie sich wie noeviction verhalten, wenn kein Schlüssel eine Ablaufzeit besitzt. WordPress speichert die meisten Einträge im Object Cache ohne TTL. Daher kann volatile-lru in einem Object Cache den verfügbaren Speicher vollständig belegen und anschließend Schreibvorgänge ablehnen. allkeys-lfu ist eine sinnvolle Alternative, wenn Ihr Datenverkehr sehr häufig auf eine kleine Gruppe von Schlüsseln zugreift, da diese Richtlinie nach Zugriffshäufigkeit statt nach Aktualität verwirft. Wählen Sie die Richtlinie bewusst und dokumentieren Sie den Grund.

Persistenz: Deaktivieren Sie sie, sofern kein konkreter Grund dafür besteht

Das Paket redis.conf aktiviert RDB-Snapshots mit Zeilen wie save 900 1 und deaktiviert die Append-only-Datei. Für einen reinen Objekt-Cache bringen Snapshots keinen Nutzen. Die Daten lassen sich per Definition neu erzeugen. Ein Cache, der aus einer zwanzig Minuten alten Datei wiederhergestellt wurde, enthält veraltete Werte, denen WordPress vertrauen wird.

Snapshots verursachen außerdem zusätzliche Kosten. BGSAVE erstellt einen Fork des Prozesses. Durch Copy-on-Write kann der Speicherverbrauch stark steigen, während der untergeordnete Prozess schreibt. Auf einem kleinen VPS ist das im Redis-Log zu sehen:

Can't save in background: fork: Cannot allocate memory

Beim Start erscheint häufig außerdem diese Warnung. Redis weist damit darauf hin, dass der Fork später wahrscheinlich fehlschlagen wird:

WARNING overcommit_memory is set to 0! Background save may fail under low memory condition.

Um Snapshots zu deaktivieren, setzen Sie in /etc/redis/redis.conf einen leeren Speicherzeitplan, starten Sie den Dienst neu und prüfen Sie, ob der Wert weiterhin leer ist.

save ""

sudo systemctl restart redis-server
redis-cli config get save

Aktivieren Sie die Persistenz nur, wenn dieselbe Instanz Daten enthält, die sich nicht neu erzeugen lassen, beispielsweise eine Jobwarteschlange oder Zähler für Rate-Limits. Trennen Sie die beiden Anwendungsfälle in diesem Fall. Ein Cache benötigt die Möglichkeit, Schlüssel zu entfernen. Dauerhafte Daten müssen dagegen erhalten bleiben. maxmemory und die Eviction-Richtlinie gelten für die gesamte Instanz, nicht für einen einzelnen Datenbankindex. Zwei Instanzen auf zwei Sockets sind die saubere Lösung.

Plugin installieren und den Drop-in verstehen

wp plugin install redis-cache --activate
wp redis enable
wp redis status

wp redis enable gibt bei Erfolg Object cache enabled. aus. Tatsächlich kopiert der Befehl wp-content/plugins/redis-cache/includes/object-cache.php nach wp-content/object-cache.php. Diese Kopie ist der Drop-in. Der Drop-in führt die eigentliche Arbeit aus. WordPress lädt wp-content/object-cache.php sehr früh, bevor Code eines Plugins ausgeführt wird. Dadurch ist der Cache für die gesamte Anfrage verfügbar. Ein aktives Plugin ohne vorhandenen Drop-in legt nichts im Cache ab.

Die Fehlermeldungen zeigen, welcher Teil fehlgeschlagen ist. Object cache could not be enabled. bedeutet, dass das Kopieren fehlgeschlagen ist. wp-content ist daher für den Benutzer, der WP-CLI ausführt, nicht beschreibbar. A foreign object cache drop-in was found. bedeutet, dass ein anderes Cache-Plugin diesen Dateinamen bereits verwendet. Die Lösung ist wp redis update-dropin. Wenn eine Meldung mit Redis server is unreachable: endet und anschließend der Client-Fehler erscheint, sind die Verbindungseinstellungen falsch. Gehen Sie zurück zu redis-cli ping.

Wenn das Kopieren an fehlenden Berechtigungen gescheitert ist, legen Sie die Datei manuell ab und weisen Sie sie dem Webbenutzer zu.

cp wp-content/plugins/redis-cache/includes/object-cache.php wp-content/object-cache.php
sudo chown www-data:www-data wp-content/object-cache.php

Durch das Entfernen des Plugins wird der Drop-in nicht entfernt. Führen Sie zuerst wp redis disable aus. Der Befehl gibt Object cache disabled. aus und löscht die Datei. Wenn Sie das Plugin-Verzeichnis löschen, während der Drop-in bestehen bleibt, verwendet die Website weiterhin alten Cache-Code, für den kein Plugin mehr Updates bereitstellt.

Verbindungseinstellungen in wp-config.php

Fügen Sie diese Einstellungen oberhalb der Zeile ein, die /* That's all, stop editing! */ enthält. Nach dieser Zeile definierte Konstanten werden zu spät verarbeitet.

define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_DATABASE', 0 );
define( 'WP_REDIS_PREFIX', 'shop_prod:' );

Für den Unix-Socket legen Sie das Schema und den Pfad fest. Host und Port werden dann ignoriert.

define( 'WP_REDIS_SCHEME', 'unix' );
define( 'WP_REDIS_PATH', '/run/redis/redis-server.sock' );
define( 'WP_REDIS_PREFIX', 'shop_prod:' );

WP_REDIS_MAXTTL erzwingt für jeden Schlüssel ein Ablaufintervall in Sekunden. Zusammen mit allkeys-lru benötigen Sie diese Einstellung nicht. Sie ist sinnvoll, wenn Sie eine feste Obergrenze dafür festlegen möchten, wie veraltet ein zwischengespeicherter Wert sein darf.

Ein Redis, mehrere Websites: Präfixe und Datenbanken

Redis stellt standardmäßig 16 nummerierte Datenbanken bereit. Jede Datenbank enthält einen gemeinsamen Schlüsselbereich. Zwei WordPress-Installationen, die ohne Präfix auf Datenbank 0 zeigen, schreiben dieselben Schlüsselnamen in denselben Bereich. Dadurch kann eine Website die Optionen der anderen lesen und ausliefern. Geben Sie jeder Website ein eigenes Präfix.

define( 'WP_REDIS_PREFIX', 'shopA_prod:' );
define( 'WP_REDIS_DATABASE', 1 );

Das Präfix trennt die Schlüsselnamen. Der Datenbankindex trennt die Schlüsselbereiche. Das ist beim Leeren wichtig: Wenn Sie einen Index leeren, bleiben die anderen unverändert. Das Plugin dokumentiert außerdem WP_REDIS_SELECTIVE_FLUSH. Damit werden nur die Schlüssel gelöscht, die zu Ihrem Präfix passen, statt die gesamte Datenbank zu leeren. Dafür müssen diese Schlüssel gesucht werden.

Präfixe und Indizes trennen den Speicher jedoch nicht. maxmemory und die Eviction-Richtlinie gelten für die gesamte Instanz. Eine stark ausgelastete Website kann daher die Schlüssel einer wenig ausgelasteten Website verdrängen, ohne dass eine der beiden Websites dies meldet. Websites, die sich gegenseitig nicht beeinflussen dürfen, benötigen separate Redis-Instanzen. Jede Instanz erhält ihren eigenen Socket und ihr eigenes Limit.

Staging aus dem Produktions-Cache heraushalten

Eine Staging-Site ist normalerweise eine Kopie der Produktionsdateien und der Produktionsdatenbank. Damit ist sie auch eine Kopie von wp-config.php und verwendet dasselbe Präfix sowie denselben Datenbankindex. Wenn Sie sie auf denselben Redis-Server zeigen lassen, schreibt sie die Schlüssel der Produktion mit Staging-Werten. Ein Testpreis oder eine geänderte Option erscheint dann ohne Deployment und ohne Protokolleintrag auf der Live-Site.

Vergeben Sie für jede Umgebung manuell einen eigenen Salt-Wert. In wp-config.php der Staging-Umgebung:

define( 'WP_REDIS_PREFIX', 'shop_staging:' );
define( 'WP_REDIS_DATABASE', 5 );

Noch besser ist eine eigene Redis-Instanz für Staging oder gar kein Objekt-Cache. define( 'WP_REDIS_DISABLED', true ); deaktiviert den Cache zur Laufzeit und lässt den Drop-in an Ort und Stelle. Das ist zugleich der schnellste Weg, um zu prüfen, ob ein Fehler durch den Cache verursacht wird.

Ältere Tutorials setzen dafür WP_CACHE_KEY_SALT. Die Readme des Plugins kennzeichnet diese Konstante als veraltet und nennt WP_REDIS_PREFIX als Ersatz. Verwenden Sie daher den neuen Namen.

Prüfen statt vertrauen

Beginnen Sie mit den eigenen Diagnosefunktionen des Plugins.

wp redis status

Die wichtigste Zeile ist Drop-in. Drop-in: Valid bedeutet, dass WordPress die Datei dieses Plugins lädt. Drop-in: Not installed bedeutet, dass das Kopieren nie stattgefunden hat und die Website keinen persistenten Cache besitzt, unabhängig davon, wie grün die Administrationsoberfläche aussieht. Status meldet die Verbindung. Client nennt die verwendete Erweiterung. Dort bestätigen Sie, dass PhpRedis und nicht Predis verwendet wird.

Fragen Sie anschließend den WordPress-Core direkt ab. Er berücksichtigt nicht, was das Plugin annimmt.

wp eval 'var_dump( wp_using_ext_object_cache() );'

bool(true) bedeutet, dass der Core mit einem externen Object Cache kommuniziert.

Weisen Sie danach mit dem konfigurierten Präfix nach, dass Schlüssel ankommen.

redis-cli -n 0 dbsize
redis-cli -n 0 --scan --pattern 'shop_prod:*' | head

Wenn dbsize steigt, während Sie durch die Website navigieren, ist das der Beweis. Null Schlüssel bei einem gültigen Drop-in bedeutet, dass die Verbindung unbemerkt fehlschlägt oder dass das Präfix nicht dem erwarteten Präfix entspricht.

Prüfen Sie abschließend, was Redis für Sie misst.

redis-cli info stats | grep -E 'keyspace_hits|keyspace_misses|evicted_keys|expired_keys'

Die Trefferquote ist keyspace_hits / (keyspace_hits + keyspace_misses). Die Redis-Dokumentation gibt diese Formel an. Beachten Sie dabei zwei Punkte. Die Zähler gelten für die gesamte Instanz seit ihrem letzten Neustart. Sie umfassen daher alle Websites und Anwendungen, die diese Instanz gemeinsam nutzen. Außerdem ist die Quote unmittelbar nach einem Flush oder Neustart nicht aussagekräftig, weil der Cache noch gefüllt wird. Lassen Sie ihn einen normalen Tag mit Netzwerkverkehr laufen.

Vergleichen Sie Ihren Wert nicht mit einer von einem Hosting-Anbieter veröffentlichten Trefferquote oder Abfrageanzahl. Diese Werte beschreiben dessen Websites und dessen Plugin-Auswahl. Maßgeblich ist Ihr eigener Wert, gemessen vor und nach der Aktivierung auf einer Seite, die ein Page Cache nicht ausliefern kann.

curl -o /dev/null -s -w '%{time_starttransfer}\n' -b cookies.txt https://example.com/my-account/

Führen Sie den Test mit einem angemeldeten Cookie-Jar mehrmals aus, zuerst mit deaktiviertem Cache (WP_REDIS_DISABLED) und anschließend mit aktiviertem Cache. Diese Differenz ist Ihr Ergebnis.

Wenn Redis WordPress verlangsamt

Eine vollständig belegte Instanz mit der falschen Policy ist der wichtigste Fall, der weiter oben behandelt wurde: OOM command not allowed when used memory > 'maxmemory'. im Log und eine Website, die sowohl für die Datenbank als auch für den Cache bezahlt.

Redis auf einem anderen Host ist der zweite Fall. WordPress führt während einer Anfrage Hunderte von Object-Cache-Aufrufen aus. Wenn eine Anfrage 500 Aufrufe ausführt und jeder Roundtrip 1 ms dauert, entsteht eine halbe Sekunde Wartezeit, die bei einem lokalen Socket nicht anfallen würde. Betreiben Sie Redis auf demselben Server oder in einem privaten Netzwerk mit einer Latenz von unter 1 ms.

Eine sehr große Tabelle mit automatisch geladenen Optionen ist der dritte Fall. Das kommt auf älteren Websites häufig vor. WordPress cached alle automatisch geladenen Optionen als einen Schlüssel. Dadurch wird bei jeder einzelnen Anfrage ein Megabyte dieser Daten über die Verbindung übertragen. Messen Sie die Größe:

wp db query "SELECT ROUND(SUM(LENGTH(option_value))/1024) AS kb FROM wp_options WHERE autoload IN ('yes','on','auto','auto-on');"

WordPress 6.6 hat neue Autoload-Werte eingeführt. Eine ältere Abfrage, die nur 'yes' berücksichtigt, unterschätzt daher die Größe bei einer aktuellen Installation. Alles über 1 Megabyte muss in der Optionstabelle behoben werden, nicht in Redis.

Ein Neustart leert den gesamten Cache. Daher sind die Minuten nach systemctl restart redis-server von Cache Misses und Datenbankzugriffen geprägt. Starten Sie den Dienst bei geringem Netzwerkverkehr neu. Ein Object Cache verhindert außerdem nicht, dass wp-cron.php beim Laden von Besucher-Seiten ausgeführt wird. Das ist eine eigene Ursache für langsame Anfragen: verschieben Sie WP-Cron in einen echten system cron job, solange Sie diese Konfiguration bearbeiten.

Aufräumen

Leeren Sie den Cache nach einem Deployment, das Optionen oder Theme-Code ändert, mit wp cache flush. Führen Sie wp redis update-dropin nach einem Plugin-Update aus, wenn das Drop-in nicht automatisch aktualisiert wurde. Ein Drop-in einer älteren Plugin-Version in Kombination mit einem neueren Plugin ist eine konkrete Ursache für ungewöhnliches Verhalten. Überwachen Sie einen Live-Server mit redis-cli --stat. Der Befehl gibt eine Zeile pro Sekunde aus. redis-cli monitor gibt jeden Befehl aus und verursacht auf einer ausgelasteten Instanz eine echte CPU-Last. Verwenden Sie den Befehl daher nur einige Sekunden lang, während Sie ein Problem reproduzieren, und beenden Sie ihn anschließend.

Eine letzte wichtige Zahl ist redis-cli info clients. Der Befehl meldet connected_clients. PHP-FPM hält pro Worker eine Verbindung. Dieser Wert sollte daher ungefähr Ihrem pm.max_children entsprechen und nicht um eine Größenordnung darüber liegen. Ist das der Fall, öffnet ein Prozess Verbindungen und schließt sie nicht.

FAQ

Benötige ich weiterhin einen Page Cache, wenn ich einen Redis-Objekt-Cache betreibe?

Ja, für anonymen Datenverkehr. Ein Page Cache liefert gespeichertes HTML aus, ohne PHP auszuführen. Das ist immer günstiger, als WordPress mit einem gefüllten Objekt-Cache auszuführen. Der Objekt-Cache übernimmt die Anfragen, die ein Page Cache überspringen muss: angemeldete Benutzer, Warenkörbe, Checkout und wp-admin. Auf einem Shop oder einer Mitgliederseite lohnt sich der Betrieb beider Caches. Auf einer Website, deren Besucher sich nie anmelden, übernimmt der Page Cache fast die gesamte Arbeit.

Wie viel Arbeitsspeicher sollte ich Redis für WordPress zuweisen?

Leiten Sie den Wert aus Ihrem eigenen Server ab, statt eine Vorgabe zu übernehmen. Ziehen Sie vom gesamten RAM den MySQL-Pufferpool und die Puffer pro Verbindung ab. Ziehen Sie außerdem pm.max_children multipliziert mit der residenten Größe eines PHP-FPM-Workers ab. Berücksichtigen Sie zusätzlich einige hundert Megabytes für Kernel und Webserver. Weisen Sie Redis einen Teil des verbleibenden Speichers zu. Prüfen Sie nach einem Tag mit Datenverkehr used_memory_human in redis-cli info memory und passen Sie den Wert an. Eine einzelne WordPress-Website benötigt normalerweise einige Dutzend Megabytes. Daher ist ein 256-MB-maxmemory auf einem 4-GB-Server ein großzügiger Startwert.

Warum wurde meine Website nach der Aktivierung des Redis-Objekt-Caches langsamer?

Die häufigste Ursache ist eine vollständig belegte Instanz, die die Richtlinie noeviction verwendet. Redis lehnt neue Schreibvorgänge ab und gibt OOM command not allowed when used memory > 'maxmemory'. zurück. WordPress greift dann für jeden Wert auf die Datenbank zurück und verursacht zusätzlich einen unnötigen Redis-Roundtrip. Prüfen Sie redis-cli config get maxmemory-policy, setzen Sie allkeys-lru und stellen Sie sicher, dass maxmemory nicht zu klein ist. Weitere häufige Ursachen sind ein Redis-Server auf einem entfernten Host, bei dem sich Hunderte Roundtrips pro Anfrage summieren, sowie ein mehrere Megabytes großer, automatisch geladener Optionswert, der bei jeder Anfrage über die Verbindung übertragen wird.

Können mehrere WordPress-Websites einen Redis-Server gemeinsam nutzen?

Ja, wenn Sie dabei sorgfältig vorgehen. Geben Sie jeder Website ein eindeutiges WP_REDIS_PREFIX, damit keine Schlüsselnamen kollidieren, sowie einen separaten WP_REDIS_DATABASE-Index, damit das Leeren des Caches einer Website nicht den Cache einer anderen Website leert. Gemeinsam genutzt wird weiterhin der Arbeitsspeicher: maxmemory und die Verdrängung gelten für die gesamte Instanz. Eine stark ausgelastete Website kann daher die Schlüssel einer wenig ausgelasteten Website verdrängen. Websites, die sich nicht gegenseitig beeinflussen dürfen, benötigen separate Redis-Instanzen mit eigenen Limits.

Ist es sicher, wp-content/object-cache.php zu löschen?

Ja. Die Datei ist ein Drop-in und gehört nicht zum WordPress-Kern. Wenn Sie sie entfernen, verwendet WordPress wieder seinen integrierten Cache pro Anfrage. Die Website funktioniert weiter, führt aber einfach mehr Datenbankabfragen aus. Verwenden Sie bevorzugt wp redis disable. Dieser Befehl löscht die Datei sauber und meldet Object cache disabled.. Wenn Redis ausgefallen ist oder fehlerhaft arbeitet und Sie den Administrationsbereich nicht erreichen, ist das manuelle Löschen der Datei die richtige Notfallmaßnahme.