Redis object cache voor WordPress instellen op VPS

Wat een Redis object cache doet voor WordPress

Een Redis object cache voor WordPress slaat de resultaten van databasequery's op in het geheugen, zodat het volgende verzoek deze uit Redis leest in plaats van opnieuw MySQL te bevragen. WordPress heeft al een object cache in de core, WP_Object_Cache, maar deze bevindt zich in het PHP-geheugen en wordt verwijderd zodra het verzoek is voltooid. Een drop-in bestand vervangt dit door een variant die communiceert met Redis, waardoor de cache behouden blijft tussen verzoeken.

Object caching is geen page caching, en het verschil bepaalt of deze handleiding voor u relevant is. Een page cache slaat de voltooide HTML van een URL op en serveert deze opnieuw zonder PHP uit te voeren. Dat is sneller dan alles wat Redis kan doen, en het werkt voor bezoekers die niet zijn ingelogd. Zodra iemand inlogt, een item in een winkelwagen plaatst of de admin opent, treedt de page cache terug en voert WordPress het volledige verzoek uit: bootstrap, plugins, query's. Een object cache maakt dat verzoek goedkoper. Het is het instrument voor het verkeer dat een page cache niet kan afhandelen: ingelogde sessies, winkelwagens, afrekenen, wp-admin. Bij een WooCommerce-winkel is dat het merendeel van het kostbare verkeer.

Beide technieken vullen elkaar aan, en op een drukke site horen ze beide thuis. Wees duidelijk over welk probleem u oplost. Een informatieve website met anonieme lezers haalt bijna alle snelheidswinst uit een page cache; het toevoegen van Redis verandert daar weinig aan.

Eén eerlijke kanttekening voordat u begint. Een object cache maakt een trage query niet snel. Het verwijdert de herhaling van een query die al is uitgevoerd. Het eerste verzoek na een misser betaalt de volledige prijs, dus een plugin die een query zonder index uitvoert, voert deze nog steeds één keer uit per cache-levensduur.

Wat u eerst nodig heeft

• Een Linux VPS met een shell en sudo. Een configuratiescherm is niet vereist.
• WordPress geserveerd via PHP-FPM, bijvoorbeeld op een LAMP-stack op Ubuntu 24.04.
• WP-CLI op de server. Elke stap hier heeft een equivalent in het beheerscherm, maar de shell-versie is sneller.
• Redis op dezelfde machine als PHP. Latency is de voornaamste reden voor deze opzet, en een netwerkhop tenietdoet dit voordeel.

Onderstaande commando's zijn geschreven voor Ubuntu 24.04 met PHP 8.3 en de www-data webgebruiker. Pas de PHP-versie en de gebruiker aan uw eigen omgeving aan. Voer de wp commando's uit vanuit uw WordPress-map, de map die wp-config.php bevat.

Redis en de PHP-extensie installeren

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

redis-cli ping hoort met PONG te antwoorden. Als de uitvoer Could not connect to Redis at 127.0.0.1:6379: Connection refused is, draait de server niet; lees in dat geval systemctl status redis-server voordat u verdergaat.

php-redis is PhpRedis, de C-extensie van PECL. Deze is sneller dan Predis, dat volledig in PHP is geschreven, en de plugin gebruikt deze automatisch wanneer deze aanwezig is. PHP-FPM laadt extensies bij het opstarten; een nieuwe extensie is daarom pas zichtbaar nadat u de pool opnieuw hebt opgestart.

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

Wees voorzichtig met die laatste controle: php -m toont de modules van de PHP command line, terwijl FPM een andere set kan laden. De controle die telt, is de eigen diagnostiek van de plugin, verderop in deze handleiding.

Sinds augustus 2026 levert Ubuntu 24.04 Redis 7.0.15, wat volstaat als objectcache. Als u een actuelere release wenst, publiceert Redis een eigen APT-repository.

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

Als uw distributie Valkey levert, de fork die ontstond na de licentiewijziging in 2024, dan gebruikt deze hetzelfde protocol en is alles hieronder ongewijzigd van toepassing.

Bind Redis zodat niets anders het kan bereiken

Redis heeft standaard geen wachtwoord. Alles wat een verbinding kan openen naar poort 6379 kan elke gecachte waarde lezen en FLUSHALL uitvoeren. Instanties die aan het internet worden blootgesteld, worden binnen enkele uren door scanners gevonden, dus de netwerkinstelling komt vóór de optimalisatie.

Open /etc/redis/redis.conf en bevestig deze regels:

bind 127.0.0.1 -::1
protected-mode yes

Controleer vervolgens wat er daadwerkelijk luistert, want het configuratiebestand is een bewering en ss is het bewijs.

sudo ss -lntp | grep 6379

127.0.0.1:6379 is wat u wilt zien. 0.0.0.0:6379 betekent dat Redis antwoordt op de publieke interface: corrigeer de bind regel en herstart.

Wanneer PHP en Redis op dezelfde machine staan, is een Unix-socket beter dan loopback TCP. Er is geen TCP-stack in het pad en de toegang wordt bepaald door bestandsrechten in plaats van door een firewallregel die u later wellicht wijzigt.

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

De socket is eigendom van de redis gebruiker en groep, dus de webgebruiker moet lid worden van die groep.

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

Dat moet ook PONG weergeven. Could not connect to Redis at /run/redis/redis-server.sock: Permission denied betekent dat de groep niet van kracht is geworden. Controleer id www-data en onthoud dat een draaiende PHP-FPM de groepen behoudt die het bij de start had; daarom staat de herstart in de lijst. Laat TCP ingeschakeld totdat de socket is getest, anders zorgt een typefout ervoor dat beide paden tegelijkertijd wegvallen.

Hoeveel geheugen moet Redis krijgen?

Bepaal dit getal op basis van uw eigen server. Redis zonder maxmemory groeit totdat de kernel geen geheugen meer heeft en de OOM killer een proces beëindigt; meestal het grootste proces, wat op een WordPress-server vaak MySQL is. journalctl -k | grep -i "out of memory" toont die beëindiging achteraf, maar dan is de site al onbereikbaar.

Begin bij het totale RAM-geheugen en trek daar zaken vanaf. MySQL of MariaDB reserveert innodb_buffer_pool_size plus buffers per verbinding. PHP-FPM kost pm.max_children vermenigvuldigd met de werkelijke resident size van één worker, doorgaans 64 MB tot 128 MB op een site met veel plugins. De kernel en de webserver vereisen enkele honderden megabytes. Wat overblijft is uw limiet, en Redis krijgt daar een deel van.

Meet nu in plaats van te gokken. Na een dag met werkelijk verkeer:

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

Als used_memory_human ver onder uw limiet blijft, verlaag dan de limiet en geef het RAM terug aan MySQL, dat dit efficiënter zal benutten. Als het tegen de limiet aanloopt en evicted_keys de hele dag oploopt, verhoog deze dan. Stel de waarde in via /etc/redis/redis.conf.

maxmemory 256mb
maxmemory-policy allkeys-lru

redis-cli config set maxmemory 256mb is direct van toepassing, maar wordt vergeten bij de volgende herstart; dit is dezelfde valkuil als bij een kale sysctl -w. Bewerk het bestand, voer daarna sudo systemctl restart redis-server uit en lees de waarde opnieuw uit. Een tweede vangnet is aan te raden: een MemoryMax-limiet op de systemd-unit voorkomt dat een verkeerd geconfigureerde Redis de hele server platlegt. Stel deze hoger in dan maxmemory, nooit gelijk eraan, omdat een cgroup-limiet het proces direct beëindigt in plaats van een key te verwijderen. Als Redis in een container naast WordPress draait, hoort hetzelfde getal in de geheugenlimieten in uw Compose-bestand thuis, en dezelfde redenering bepaalt de keuze voor het draaien van de database in Docker of op de host.

Kies bewust het eviction-beleid

Een nieuwe Redis-installatie gebruikt standaard noeviction. Controleer uw instelling:

redis-cli config get maxmemory-policy

Onder noeviction stopt een volledige instantie met het accepteren van schrijfacties en geeft het volgende antwoord:

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

Deze enkele regel is de meest problematische foutmodus in deze handleiding, omdat de site niet volledig offline gaat. De site wordt trager. Elke cache-schrijfactie mislukt, waardoor WordPress voor de waarde terugvalt op de database, om deze vervolgens bij het volgende verzoek opnieuw te proberen op te slaan, wat weer mislukt. De site voert nu al het oorspronkelijke databasewerk uit plus een extra netwerkverzoek naar Redis voor elke sleutel. Niets in het WordPress-beheerpaneel geeft aan dat dit gebeurt. De melding verschijnt in het PHP-foutenlogboek; gebruik daarom grep voor OOM command not allowed wanneer een site trager wordt nadat u een cache heeft toegevoegd.

allkeys-lru is hier de juiste standaardinstelling. Redis verwijdert de minst recent gebruikte sleutel wanneer het geheugen vol raakt. Dit is precies wat een object-cache nodig heeft, omdat elke waarde daarin een kopie is van gegevens die nog steeds in MySQL bestaan. Het verliezen van een sleutel kost één query. Het weigeren van een schrijfactie kost elke query, bij elk verzoek, totdat iemand het opmerkt.

Vermijd de volatile-*-beleidsregels voor deze taak. Deze houden alleen rekening met sleutels die een verloopdatum hebben, en de Redis-documentatie stelt dat ze zich gedragen als noeviction wanneer geen enkele sleutel een verloopdatum heeft. WordPress slaat de meeste object-cache-items op zonder TTL, waardoor volatile-lru bij een object-cache vol kan raken en schrijfacties kan gaan weigeren. allkeys-lfu is een redelijk alternatief als uw verkeer zeer vaak een kleine set sleutels raakt, aangezien dit beleid verwijdert op basis van frequentie in plaats van recentheid. Kies bewust een beleid en noteer de reden voor uw keuze.

Persistentie: laat dit uitgeschakeld tenzij u een specifieke reden heeft

Het pakket redis.conf schakelt RDB-snapshots in met regels zoals save 900 1, en laat het append-only bestand uitgeschakeld. Voor een pure object-cache leveren snapshots geen voordeel op. De data is per definitie opnieuw op te bouwen, en een cache die wordt hersteld vanuit een bestand van twintig minuten oud bevat verouderde waarden die WordPress als correct zal beschouwen.

Snapshots kosten bovendien resources. BGSAVE splitst het proces (fork), en door copy-on-write kan het geheugengebruik scherp stijgen terwijl het child-proces schrijft. Op een kleine VPS is dit zichtbaar in de Redis-log:

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

en vaak verschijnt deze waarschuwing bij het opstarten, waarmee Redis aangeeft dat de fork later waarschijnlijk zal falen:

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

Om snapshots uit te schakelen, stelt u een leeg save-schema in binnen /etc/redis/redis.conf, start u de service opnieuw en bevestigt u dat de waarde leeg is teruggekeerd.

save ""

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

Gebruik persistentie alleen als dezelfde instantie data bevat die u niet opnieuw kunt opbouwen, zoals een takenwachtrij of rate-limit counters. Splits in dat geval de twee functies. Een cache vereist dat keys worden verwijderd (eviction), terwijl duurzame data vereist dat keys behouden blijven. Omdat maxmemory en eviction op de gehele instantie van toepassing zijn en niet op een individuele database-index, is het draaien van twee instanties op twee sockets de juiste oplossing.

Installeer de plugin en begrijp de drop-in

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

wp redis enable geeft Object cache enabled. weer bij succes. Wat het commando feitelijk doet, is wp-content/plugins/redis-cache/includes/object-cache.php kopiëren naar wp-content/object-cache.php. Die kopie is de drop-in, en de drop-in is het onderdeel dat het werk verricht. WordPress laadt wp-content/object-cache.php zeer vroeg, nog voordat enige plugin-code wordt uitgevoerd; dit is de reden waarom de cache beschikbaar is voor het gehele verzoek. Een actieve plugin zonder aanwezige drop-in cachet niets.

De foutmeldingen geven aan welk deel is mislukt. Object cache could not be enabled. betekent dat het kopiëren is mislukt, omdat wp-content niet beschrijfbaar is voor de gebruiker die WP-CLI uitvoert. A foreign object cache drop-in was found. betekent dat een andere caching-plugin dat bestandsnaam al in gebruik heeft; de oplossing is wp redis update-dropin. Een melding die eindigt op Redis server is unreachable:, gevolgd door de client-fout, betekent dat de verbindingsinstellingen onjuist zijn; keer in dat geval terug naar redis-cli ping.

Als het kopiëren is mislukt vanwege rechten, plaats het bestand dan handmatig en wijs het toe aan de webgebruiker.

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

Het verwijderen van de plugin verwijdert de drop-in niet. Voer eerst wp redis disable uit; dit geeft Object cache disabled. weer en verwijdert het bestand. Verwijder de plugin-directory niet terwijl de drop-in achterblijft, anders blijft de site oude cache-code uitvoeren zonder dat er een plugin is om deze bij te werken.

Verbindingsinstellingen in wp-config.php

Voeg deze toe boven de regel die /* That's all, stop editing! */ bevat, omdat constanten die daarna worden gedefinieerd niet tijdig worden verwerkt.

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

Stel voor de Unix-socket het schema en het pad in. Host en poort worden in dat geval genegeerd.

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

WP_REDIS_MAXTTL dwingt een verloopdatum af voor elke sleutel, uitgedrukt in seconden. U heeft dit niet nodig in combinatie met allkeys-lru, en het is nuttig als u een strikte bovengrens wilt stellen aan hoe verouderd een gecachte waarde mag zijn.

Eén Redis, meerdere sites: prefixen en databases

Redis biedt standaard zestien genummerde databases, elk met één platte keyspace. Twee WordPress-installaties die naar database 0 wijzen zonder prefix, schrijven dezelfde sleutelnamen in dezelfde ruimte. Hierdoor kan de ene site de opties van de andere site lezen en serveren. Geef elke site daarom een eigen prefix.

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

De prefix scheidt de sleutelnamen. De database-index scheidt de keyspaces, wat van belang is bij het legen van de database: het leegmaken van één index laat de andere ongemoeid. De plugin documenteert ook WP_REDIS_SELECTIVE_FLUSH, waarmee alleen de sleutels die overeenkomen met uw prefix worden verwijderd in plaats van de gehele database. Dit gaat ten koste van de prestaties, omdat de database hiervoor moet worden gescand.

Wat prefixen en indexen niet scheiden, is het geheugen. maxmemory en het eviction-beleid zijn van toepassing op het geheugen van de gehele instantie. Een drukke site kan de sleutels van een rustige site uit het geheugen verdringen zonder dat een van beide sites dit rapporteert. Sites die elkaar onder geen beding mogen beïnvloeden, vereisen aparte Redis-instanties, elk met een eigen socket en een eigen limiet.

Houd staging gescheiden van de cache van productie

Een staging-omgeving is doorgaans een kopie van de bestanden en de database van de productieomgeving. Dit betekent dat het een kopie is van wp-config.php die hetzelfde voorvoegsel en dezelfde database-index gebruikt. Als u deze naar dezelfde Redis-instantie laat wijzen, overschrijft staging de keys van productie met staging-waarden. Een testprijs of een gewijzigde optie verschijnt dan op de live-site zonder dat er een deploy heeft plaatsgevonden en zonder sporen na te laten.

Voorzie elke omgeving handmatig van een unieke salt. In de wp-config.php van staging:

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

Beter nog: geef staging een eigen Redis-instantie, of gebruik helemaal geen object cache. define( 'WP_REDIS_DISABLED', true ); schakelt de cache uit tijdens runtime en laat het drop-in bestand staan; dit is tevens de snelste manier om te verifiëren of een bug wel of niet door de cache wordt veroorzaakt.

Oudere handleidingen gebruiken hiervoor WP_CACHE_KEY_SALT. De readme van de plugin markeert deze constante als verouderd en vervangen door WP_REDIS_PREFIX, gebruik daarom de nieuwe naam.

Controleer het in plaats van erop te vertrouwen

Begin met de eigen diagnostiek van de plugin.

wp redis status

De regel die het belangrijkst is, is Drop-in. Drop-in: Valid betekent dat WordPress het bestand van deze plugin laadt. Drop-in: Not installed betekent dat het kopiëren nooit heeft plaatsgevonden en dat de site geen persistente cache heeft, hoe groen het beheerscherm er ook uitziet. Status rapporteert de verbinding en Client noemt de gebruikte extensie; hier bevestigt u of het PhpRedis is in plaats van Predis.

Vraag het vervolgens direct aan de WordPress-kern, aangezien deze niet geeft om wat de plugin denkt.

wp eval 'var_dump( wp_using_ext_object_cache() );'

bool(true) betekent dat de kern communiceert met een externe objectcache.

Bewijs vervolgens dat de keys aankomen, met het voorvoegsel dat u heeft geconfigureerd.

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

dbsize dat oploopt terwijl u door de site klikt, is het bewijs. Nul keys bij een geldige drop-in betekent dat de verbinding stilletjes faalt, of dat het voorvoegsel niet het voorvoegsel is dat u denkt.

Kijk tot slot naar wat Redis voor u meet.

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

De hit-ratio is keyspace_hits / (keyspace_hits + keyspace_misses), en de documentatie van Redis geeft die formule. Lees deze met twee waarschuwingen. De tellers beslaan het gehele exemplaar sinds de laatste herstart, dus ze vermengen elke site en elke applicatie die er gebruik van maakt. En de ratio direct na een flush of een herstart betekent niets, omdat de cache nog gevuld moet worden. Laat het een normale dag met netwerkverkeer draaien.

Vergelijk uw cijfer niet met een hit-rate of een query-aantal dat door een hostingbedrijf is gepubliceerd. Die beschrijven hun sites en hun set plugins. Het cijfer dat ertoe doet is dat van uzelf, gemeten voor en na op een pagina die een paginacache niet kan serveren.

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

Voer dat uit met een ingelogde cookie-jar, meerdere keren, met de cache uitgeschakeld (WP_REDIS_DISABLED) en daarna ingeschakeld. Dat verschil is uw resultaat.

Wanneer Redis WordPress trager maakt

Een volledige instance met het verkeerde beleid is de belangrijkste oorzaak, zoals hierboven besproken: OOM command not allowed when used memory > 'maxmemory'. in het logbestand, waarbij een site zowel voor de database als voor de cache betaalt.

Redis op een andere host is de tweede oorzaak. WordPress voert honderden object cache-aanroepen uit in één verzoek. Als een verzoek 500 aanroepen doet en elke round-trip 1 ms kost, is dat een halve seconde wachttijd die een lokale socket niet zou hebben. Houd Redis op dezelfde machine, of op een privénetwerk met een latentie van minder dan een milliseconde. Hoeveel de lokale opstelling wint door de kernel is een aparte vraag: de cache-aware scheduling toegevoegd in Linux 7.2 probeert spraakzame processen zoals PHP-FPM en Redis op cores te houden die een cache delen, en een VPS-guest ziet daar minder van dan bare metal.

Een enorme autoloaded options-tabel is de derde oorzaak, en dit komt veel voor bij oude sites. WordPress slaat alle autoloaded opties op als één key, waardoor er bij elk verzoek een megabyte aan data over de verbinding gaat. Meet dit:

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 heeft nieuwe autoload-waarden toegevoegd, dus een oudere query die alleen op 'yes' filtert, geeft een vertekend beeld bij een moderne installatie. Alles boven een megabyte is een probleem dat in de options-tabel moet worden opgelost, niet in Redis.

Een herstart leegt alles, dus de minuten na systemctl restart redis-server bestaan volledig uit misses en database-activiteit. Herstart wanneer het verkeer laag is. Een object cache voorkomt bovendien niet dat wp-cron.php wordt geactiveerd bij het laden van pagina's door bezoekers, wat op zichzelf een bron van trage verzoeken is: verplaats WP-Cron naar een echte system cron job terwijl u hier toch bezig bent.

Onderhoud

Voer een flush uit na een implementatie die opties of themacode wijzigt met wp cache flush. Voer wp redis update-dropin uit na een plugin-update als de drop-in zichzelf niet heeft bijgewerkt, aangezien een drop-in van een oudere plugin-versie in combinatie met een nieuwere plugin vaak vreemd gedrag veroorzaakt. Monitor een live server met redis-cli --stat, dat één regel per seconde afdrukt. redis-cli monitor drukt elk commando af en verbruikt aanzienlijke CPU-capaciteit op een drukke instantie; gebruik dit daarom slechts enkele seconden terwijl u een probleem reproduceert en stop het daarna direct.

Eén laatste getal dat nuttig is om te kennen: redis-cli info clients rapporteert connected_clients. PHP-FPM houdt één verbinding per worker vast, dus dat cijfer moet in lijn zijn met uw pm.max_children en deze niet met een factor tien overschrijden. Als dat wel het geval is, opent een proces verbindingen die niet worden gesloten.

FAQ

Heb ik nog steeds een page cache nodig als ik een Redis object cache gebruik?

Ja, voor anoniem verkeer. Een page cache serveert opgeslagen HTML zonder PHP uit te voeren, wat altijd minder resources kost dan het draaien van WordPress met een warme object cache. De object cache verwerkt de verzoeken die een page cache moet overslaan: ingelogde gebruikers, winkelwagens, het afrekenproces en wp-admin. Op een webshop of een ledensite is het zinvol om beide te gebruiken. Op een site waar bezoekers nooit inloggen, doet de page cache vrijwel al het werk.

Hoeveel geheugen moet ik aan Redis toewijzen voor WordPress?

Baseer dit op uw eigen server in plaats van een willekeurig getal over te nemen. Neem het totale RAM-geheugen, trek daar de MySQL buffer pool en de buffers per verbinding vanaf, trek pm.max_children vermenigvuldigd met de resident size van één PHP-FPM worker af, en trek enkele honderden megabytes af voor de kernel en de webserver. Wijs een deel van wat overblijft toe aan Redis, controleer daarna used_memory_human in redis-cli info memory na een dag verkeer en pas dit aan. Een enkele WordPress-site verbruikt meestal enkele tientallen megabytes, dus een 256 MB maxmemory is een ruim startpunt op een 4 GB server.

Waarom werd mijn site trager na het inschakelen van de Redis object cache?

De gebruikelijke oorzaak is een volle instantie die het noeviction beleid hanteert. Redis weigert nieuwe schrijfacties en geeft OOM command not allowed when used memory > 'maxmemory'. terug, waardoor WordPress voor elke waarde terugvalt op de database en daarbovenop ook nog de vertraging van een nutteloze Redis-roundtrip oploopt. Controleer redis-cli config get maxmemory-policy, stel allkeys-lru in en bevestig dat maxmemory niet te klein is. Andere veelvoorkomende oorzaken zijn een Redis-server op een externe host, waarbij honderden roundtrips per verzoek optellen, en een autoloaded options-waarde van meerdere megabytes die bij elk verzoek over de verbinding wordt verstuurd.

Kunnen meerdere WordPress-sites één Redis-server delen?

Dat kan, mits u voorzichtig bent. Geef elke site een uniek WP_REDIS_PREFIX zodat sleutelnamen niet kunnen botsen, en een afzonderlijke WP_REDIS_DATABASE index zodat het legen van de cache van één site niet de andere leegt. Wat ze wel delen is het geheugen: maxmemory en eviction gelden voor de gehele instantie, dus een drukke site kan de sleutels van een rustige site verwijderen. Sites die elkaar niet mogen beïnvloeden, hebben afzonderlijke Redis-instanties met eigen limieten nodig.

Is het veilig om wp-content/object-cache.php te verwijderen?

Ja. Dit is een drop-in, geen onderdeel van de WordPress-kern, en het verwijderen ervan brengt WordPress terug naar de ingebouwde cache per verzoek. De site blijft werken en voert simpelweg meer database-queries uit. Gebruik bij voorkeur wp redis disable, wat het bestand netjes verwijdert en Object cache disabled. rapporteert. Het handmatig verwijderen is de juiste noodgreep als Redis offline is of niet naar behoren functioneert en u het admin-paneel niet kunt bereiken.