Redis-Objekt-Cache für WordPress auf dem VPS einrichten

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

Ein Redis-Objekt-Cache für WordPress speichert die Ergebnisse von Datenbankabfragen im Arbeitsspeicher. Die nächste Anfrage liest diese Ergebnisse dann aus Redis, 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 bis zur nächsten erhalten.

Objekt-Caching ist kein Seiten-Caching. Dieser Unterschied entscheidet darüber, 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. Außerdem funktioniert es für Besucher, die nicht angemeldet sind. Sobald sich jemand anmeldet, einen Artikel in einen Warenkorb legt oder den Administrationsbereich öffnet, greift der Seiten-Cache nicht mehr. WordPress verarbeitet dann die gesamte Anfrage: Bootstrap, Plugins und Abfragen. Ein Objekt-Cache macht genau diese Anfrage günstiger. Er ist für den Datenverkehr zuständig, den ein Seiten-Cache nicht abdecken kann: Sitzungen angemeldeter Benutzer, Warenkörbe, Kassenprozesse 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 dazu. Stellen Sie klar fest, welches Problem Sie beheben. Eine Informationsseite mit anonymen Lesern bezieht fast ihre gesamte Geschwindigkeit aus einem Seiten-Cache. Die Ergänzung durch Redis ändert dort nur sehr wenig.

Bevor Sie beginnen, sollten Sie eine Einschränkung kennen. Ein Objekt-Cache macht keine langsame Abfrage schnell. Er verhindert die Wiederholung einer bereits ausgeführten Abfrage. Die erste Anfrage nach einem Cache-Miss zahlt weiterhin den vollständigen Preis. Ein Plugin, das eine Abfrage ohne passenden Index ausführt, führt sie daher einmal pro Cache-Lebensdauer aus.

Was Sie zuerst benötigen

• Einen Linux-VPS mit einer Shell und sudo. Ein Control Panel ist nicht erforderlich.
• WordPress, das über PHP-FPM bereitgestellt wird, beispielsweise auf einem LAMP-Stack unter Ubuntu 24.04.
• WP-CLI auf dem System. Für jeden Schritt gibt es eine Entsprechung im Administrationsbereich. Die Shell-Variante ist schneller.
• Redis auf demselben Rechner wie PHP. Die geringe Latenz ist der entscheidende Vorteil. Ein zusätzlicher Netzwerk-Hop macht ihn 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 Ihr System an. Führen Sie die wp-Befehle aus Ihrem 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 PONG ausgeben. 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 sie automatisch, sobald sie 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

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

Stand August 2026 paketiert Ubuntu 24.04 Redis 7.0.15. Diese Version eignet sich für einen Objekt-Cache. 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

Falls Ihre Distribution Valkey ausliefert, den nach der Lizenzänderung von 2024 gestarteten Fork, verwendet es dasselbe Protokoll. Alle folgenden Schritte gelten unverändert.

Redis so binden, dass kein anderer darauf zugreifen kann

Redis verwendet standardmäßig kein Passwort. Alles, was eine Verbindung zu Port 6379 öffnen kann, kann jeden zwischengespeicherten Wert lesen und FLUSHALL ausführen. Im Internet erreichbare Instanzen werden innerhalb weniger Stunden von Scannern gefunden. Deshalb muss die Netzwerkkonfiguration vor der Optimierung erfolgen.

Öffnen Sie /etc/redis/redis.conf und prüfen Sie, ob diese Zeilen vorhanden sind:

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, während ss den tatsächlichen Zustand zeigt.

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 Loopback. Dabei wird kein TCP-Stack verwendet. Der Zugriff wird stattdessen über Dateiberechtigungen gesteuert und nicht über eine Firewall-Regel, die später geändert werden könnte.

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

Dieser Befehl muss außerdem PONG ausgeben. Could not connect to Redis at /run/redis/redis-server.sock: Permission denied bedeutet, dass die Gruppenmitgliedschaft nicht wirksam geworden ist. Prüfen Sie id www-data. Beachten Sie außerdem, dass ein laufender PHP-FPM-Prozess die Gruppenmitgliedschaften beibehält, die beim Start gültig waren. Deshalb ist der Neustart in der Liste enthalten. 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 Server ab. Redis wächst ohne maxmemory, bis der Kernel keinen Speicher mehr hat und der OOM-Killer einen Prozess beendet, meistens den größten. Auf einem WordPress-Server ist das häufig MySQL. journalctl -k | grep -i "out of memory" zeigt diesen Vorgang erst nachträglich an. Die Website ist zu diesem Zeitpunkt bereits nicht erreichbar.

Gehen Sie vom gesamten RAM aus und ziehen Sie die einzelnen Anteile 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 Ihre Obergrenze. Einen Teil davon weisen Sie Redis zu.

Messen Sie jetzt statt zu raten. Nach einem Tag mit realem Netzwerkverkehr:

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 am Limit bleibt und evicted_keys den ganzen Tag ansteigt, 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 wieder aus. Eine zweite Begrenzung ist sinnvoll: ein MemoryMax-Limit für die systemd-Unit verhindert, dass ein falsch konfiguriertes Redis den gesamten Server herunterfährt. Setzen Sie es oberhalb von maxmemory, niemals auf denselben Wert. Ein cgroup-Limit beendet den Prozess, statt einen Schlüssel zu entfernen. Wenn Redis in einem Container neben WordPress läuft, gehört derselbe Wert in die Speicherlimits Ihrer Compose-Datei. Dieselbe Überlegung bestimmt auch die Wahl zwischen dem Betrieb der Datenbank in Docker oder auf dem Host.

Wählen Sie die Eviction-Policy bewusst

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

redis-cli config get maxmemory-policy

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

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

Diese einzelne Zeile beschreibt in diesem Leitfaden den schwerwiegendsten Fehlerfall, weil die Website nicht ausfällt. Sie wird langsamer. Jeder Schreibvorgang in den Cache schlägt fehl. WordPress greift daher für den Wert auf die Datenbank zurück, 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-Adminbereich gibt es keinen Hinweis darauf. Die Zeichenfolge erscheint im PHP-Fehlerlog. 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. Das entspricht genau den Anforderungen eines 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 das Problem bemerkt.

Vermeiden Sie für diese Aufgabe die volatile-*-Policies. 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 Object-Cache-Einträge ohne TTL. Daher kann sich volatile-lru in einem Object Cache vollständig füllen und anschließend Schreibvorgänge ablehnen. allkeys-lfu ist eine geeignete Alternative, wenn Ihr Datenverkehr sehr häufig auf eine kleine Gruppe von Schlüsseln zugreift, da diese Policy nach Zugriffshäufigkeit statt nach Aktualität verwirft. Wählen Sie eine Einstellung bewusst aus und dokumentieren Sie den Grund.

Persistence: deaktiviert lassen, sofern kein Grund dafür besteht

Das paketierte redis.conf aktiviert RDB-Snapshots mit Zeilen wie save 900 1 und lässt die Append-only-Datei deaktiviert. Für einen reinen Objekt-Cache bringen Snapshots keinen Nutzen. Die Daten lassen sich definitionsgemäß 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 ansteigen, während der Kindprozess schreibt. Auf einem kleinen VPS ist das im Redis-Log sichtbar:

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

Beim Start erscheint häufig auch 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 Speicherplan, starten Sie den Dienst neu und prüfen Sie, ob der Wert wieder leer ist.

save ""

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

Lassen Sie die Persistenz nur aktiviert, wenn dieselbe Instanz Daten enthält, die sich nicht neu erstellen lassen, etwa eine Jobwarteschlange oder Rate-Limit-Zähler. Trennen Sie die beiden Anwendungsfälle in diesem Fall. Ein Cache soll Schlüssel bei Bedarf entfernen, während dauerhafte Daten erhalten bleiben sollen. maxmemory und die Eviction gelten jedoch 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 steht der Cache für die gesamte Anfrage zur Verfügung. Ein aktives Plugin ohne vorhandenen Drop-in cached nichts.

Die Fehlermeldungen zeigen, welche der beiden Hälften fehlgeschlagen ist. Object cache could not be enabled. bedeutet, dass die Kopie 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 Caching-Plugin diesen Dateinamen bereits verwendet. Die Lösung ist wp redis update-dropin. Eine Meldung, die mit Redis server is unreachable: endet, gefolgt vom Client-Fehler, weist auf falsche Verbindungseinstellungen hin. Gehen Sie dann zurück zu redis-cli ping.

Wenn die Kopie an den Berechtigungen gescheitert ist, legen Sie sie manuell an und übertragen Sie sie an den Webbenutzer.

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 den alten Cache-Code. Es ist dann kein Plugin mehr vorhanden, das diesen Code aktualisieren kann.

Verbindungseinstellungen in wp-config.php

Fügen Sie diese Zeilen 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 eine Ablaufzeit 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 höchstens sein darf.

Ein Redis, mehrere Websites: Präfixe und Datenbanken

Redis stellt standardmäßig sechzehn nummerierte Datenbanken bereit. Jede Datenbank enthält einen flachen Keyspace. Zwei WordPress-Installationen, die auf Datenbank 0 zeigen und kein Präfix verwenden, schreiben dieselben Schlüsselnamen in denselben Keyspace. Dadurch kann eine Website die Optionen der anderen Website 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 Keyspaces. 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 die passenden Schlüssel gesucht werden.

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

Staging von dem Cache der Produktion trennen

Eine Staging-Website ist normalerweise eine Kopie der Dateien und der Datenbank der Produktionsumgebung. Damit ist sie auch eine Kopie von wp-config.php mit demselben Präfix und demselben Datenbankindex. Wenn Sie sie auf dasselbe Redis zeigen lassen, schreibt sie die Schlüssel der Produktionsumgebung mit Staging-Werten. Ein Testpreis oder eine geänderte Option erscheint dann ohne Deployment und ohne Protokolleintrag auf der Live-Website.

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

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

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 das Drop-in an seinem Platz. Damit lässt sich außerdem am schnellsten feststellen, ob ein Fehler durch den Cache verursacht wird.

Ältere Tutorials setzen dafür WP_CACHE_KEY_SALT. In der Readme des Plugins ist diese Konstante als veraltet gekennzeichnet und durch WP_REDIS_PREFIX ersetzt. Verwenden Sie daher den neuen Namen.

Überprüfen statt vertrauen

Beginnen Sie mit den eigenen Diagnosen des Plugins.

wp redis status

Am wichtigsten ist die Zeile Drop-in. Drop-in: Valid bedeutet, dass WordPress die Datei dieses Plugins lädt. Drop-in: Not installed bedeutet, dass die Kopie nie erstellt wurde und die Website über keinen persistenten Cache verfügt, unabhängig davon, wie erfolgreich die Administrationsoberfläche aussieht. Status meldet die Verbindung, und Client nennt die verwendete Erweiterung. Dort bestätigen Sie, dass PhpRedis und nicht Predis verwendet wird.

Fragen Sie anschließend den WordPress-Kern direkt ab, da dieser nicht berücksichtigt, was das Plugin meldet.

wp eval 'var_dump( wp_using_ext_object_cache() );'

bool(true) bedeutet, dass der WordPress-Kern mit einem externen Objekt-Cache kommuniziert.

Weisen Sie anschließend nach, dass Schlüssel mit dem von Ihnen konfigurierten Präfix ankommen.

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

Wenn dbsize ansteigt, während Sie auf der Website navigieren, ist das der Nachweis. 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 zum Schluss, welche Werte Redis für Sie erfasst.

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 enthält diese Formel. Beachten Sie dabei zwei Punkte. Die Zähler gelten für die gesamte Instanz seit ihrem letzten Neustart. Daher enthalten sie Werte aller Websites und Anwendungen, die diese Instanz gemeinsam verwenden. Außerdem ist das Verhältnis direkt nach einem Flush oder Neustart nicht aussagekräftig, da der Cache noch gefüllt wird. Lassen Sie die Messung über einen normalen Tag mit Netzwerkverkehr laufen.

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

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

Führen Sie dies mit einem angemeldeten Cookie-Jar mehrmals aus, zunächst 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. Die Website bezahlt dabei sowohl für die Datenbank als auch für den Cache.

Redis auf einem anderen Host ist der zweite Fall. WordPress führt während einer Anfrage Hunderte von Aufrufen des Objekt-Caches aus. Wenn eine Anfrage 500 Aufrufe erzeugt und jeder Roundtrip 1 ms dauert, entstehen dadurch 0,5 Sekunden Wartezeit, die bei einem lokalen Socket nicht anfallen würden. Lassen Sie Redis auf demselben Server oder in einem privaten Netzwerk mit einer Latenz von weniger als 1 ms laufen. Wie stark der Kernel den Betrieb auf demselben Server verbessert, ist eine separate Frage: die in Linux 7.2 hinzugefügte cachebewusste Ablaufplanung versucht, kommunikationsintensive Prozesse wie PHP-FPM und Redis auf Kernen mit gemeinsamem Cache auszuführen. Ein VPS-Gast profitiert davon weniger als Bare Metal.

Eine sehr große Tabelle mit automatisch geladenen Optionen ist der dritte Fall. Sie tritt häufig auf älteren Websites auf. 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 modernen Installation. Alles oberhalb eines Megabytes muss in der Optionentabelle 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 neu, wenn das Verkehrsaufkommen gering ist. Ein Objekt-Cache verhindert außerdem nicht, dass wp-cron.php beim Laden von Besucherseiten ausgeführt wird. Das ist eine eigene Ursache für langsame Anfragen: verschieben Sie WP-Cron in einen echten system cron job, wenn Sie schon dabei sind.

Aufräumen

Leeren Sie nach einem Deployment, das Optionen oder Theme-Code ändert, den Cache 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 verursacht häufig unerwartetes 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 merkliche CPU-Last. Verwenden Sie ihn daher nur einige Sekunden, 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. Der Wert sollte daher Ihrer 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 noch einen Page-Cache, wenn ich einen Redis-Objekt-Cache verwende?

Ja, für nicht authentifizierten Traffic. 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 auslassen muss: angemeldete Benutzer, Warenkörbe, Checkout und wp-admin. In einem Shop oder auf einer Mitgliederseite lohnt sich der Betrieb beider Caches. Auf einer Website, deren Besucher sich nie anmelden, erledigt der Page-Cache fast die gesamte Arbeit.

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

Leiten Sie den Wert aus Ihrem eigenen Server ab, statt eine Zahl zu übernehmen. Ziehen Sie vom gesamten Arbeitsspeicher den MySQL-Buffer-Pool und die Buffer pro Verbindung ab. Ziehen Sie anschließend pm.max_children, multipliziert mit der residenten Größe eines PHP-FPM-Workers, sowie einige hundert Megabytes für Kernel und Webserver ab. Weisen Sie Redis einen Teil des verbleibenden Speichers zu. Prüfen Sie nach einem Tag mit echtem Traffic used_memory_human in redis-cli info memory und passen Sie den Wert an. Eine einzelne WordPress-Website benötigt normalerweise einige zehn Megabytes. Daher ist ein 256-MB-maxmemory auf einem 4-GB-Server ein großzügiger Anfangswert.

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

Die häufigste Ursache ist eine vollständig belegte Instanz mit der Richtlinie noeviction. 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 verwenden?

Ja, wenn Sie dabei sorgfältig vorgehen. Verwenden Sie für jede Website ein eindeutiges WP_REDIS_PREFIX, damit keine Schlüsselnamen kollidieren, sowie einen separaten WP_REDIS_DATABASE-Index, damit das Leeren einer Website nicht die Daten einer anderen Website löscht. Gemeinsam genutzt wird weiterhin der Arbeitsspeicher: maxmemory und die Eviction gelten für die gesamte Instanz. Daher kann eine stark ausgelastete Website 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-Core. Durch das 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. Der Befehl löscht die Datei sauber und meldet Object cache disabled.. Das manuelle Löschen ist der richtige Notfallweg, wenn Redis nicht verfügbar ist oder fehlerhaft arbeitet und Sie den Administrationsbereich nicht erreichen.