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 aan MySQL te vragen. 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 met Redis communiceert, waardoor de cache behouden blijft tussen verzoeken.

Object caching is geen page caching, en het verschil bepaalt of deze handleiding relevant voor u 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 winkelmandje 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 waar een page cache niet bij kan: ingelogde sessies, winkelmandjes, 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 beperking voordat u begint. Een object cache maakt een trage query niet snel. Het verwijdert de herhaling van een query die al eerder is uitgevoerd. Het eerste verzoek na een misser betaalt de volledige prijs, dus een plugin die een niet-geïndexeerde query 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 door PHP-FPM, bijvoorbeeld op een LAMP-stack op Ubuntu 24.04.
• WP-CLI op de server. Elke stap hier heeft een equivalent in het beheerdersscherm, maar de shell-versie is sneller.
• Redis op dezelfde machine als PHP. Latency is het voornaamste punt, en een netwerk-hop 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 server 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 PONG te antwoorden. Als het Could not connect to Redis at 127.0.0.1:6379: Connection refused afdrukt, draait de server niet; lees daarom systemctl status redis-server voordat u verdergaat.

php-redis is PhpRedis, de C-extensie van PECL. Deze is sneller dan Predis, dat uit pure PHP bestaat, en de plugin gebruikt deze automatisch wanneer deze aanwezig is. PHP-FPM laadt extensies bij het opstarten, dus een nieuwe extensie is onzichtbaar totdat u de pool herstart.

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

Wees voorzichtig met die laatste controle: php -m somt de modules van de PHP command line op, en FPM kan een andere set laden. De controle die telt, is de eigen diagnostiek van de plugin, verderop in dit document.

Sinds augustus 2026 levert Ubuntu 24.04 Redis 7.0.15, wat prima is voor een object cache. Als u in plaats daarvan een actuele release wilt, publiceert Redis zijn 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 na de licentiewijziging van 2024 is gestart, 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 met 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 gaat voor de tuning.

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 mogelijk 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 bewezen werkt, anders kan een typefout beide paden tegelijk afsluiten.

Hoeveel geheugen moet Redis krijgen?

Leid dit getal af 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 plafond, en Redis krijgt daar een deel van.

Meet nu in plaats van te gokken. Na een dag met echt 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 beter 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 vervolgens opnieuw uit. Een tweede vangnet is aan te raden: een MemoryMax-limiet op de systemd-unit voorkomt dat een verkeerd geconfigureerde Redis de server platlegt. Stel deze hoger in dan maxmemory, nooit gelijk eraan, omdat een cgroup-limiet het proces direct doodt 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 een eviction policy

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

redis-cli config get maxmemory-policy

Bij noeviction stopt een volledige instantie met het accepteren van schrijfacties en antwoordt met de volgende melding:

(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 uitvalt. De site wordt trager. Elke cache-schrijfactie mislukt, waardoor WordPress voor de waarde terugvalt op de database, deze vervolgens bij het volgende verzoek opnieuw probeert op te slaan en weer faalt. 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, aangezien 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-*-policies voor deze taak. Deze houden alleen rekening met sleutels die een verloopdatum hebben, en de documentatie van Redis 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 raadpleegt, aangezien deze policy verwijdert op basis van frequentie in plaats van recentheid. Maak een bewuste keuze en noteer waarom u deze heeft gemaakt.

Persistentie: laat dit uitgeschakeld tenzij u een 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 niets op. De data is per definitie opnieuw te genereren, en een cache die wordt hersteld vanuit een twintig minuten oud bestand bevat verouderde waarden waar WordPress op zal vertrouwen.

Snapshots kosten ook middelen. BGSAVE splitst het proces (fork), en copy-on-write betekent dat het geheugengebruik scherp kan stijgen terwijl het kindproces schrijft. Op een kleine VPS is dit zichtbaar in het Redis-logboek:

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 in /etc/redis/redis.conf, herstart u de service en bevestigt u dat de waarde leeg is teruggekomen.

save ""

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

Behoud persistentie alleen als dezelfde instantie data bevat die u niet opnieuw kunt opbouwen, zoals een takenwachtrij of rate-limit tellers. Splits in dat geval de twee. Een cache vereist dat keys worden verwijderd (eviction) en duurzame data vereist dat keys behouden blijven, en maxmemory plus eviction is van toepassing op de gehele instantie, niet op één database-index. Twee instanties op twee sockets is de schone 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; op die manier is de cache beschikbaar 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 die 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. Als u de plugin-directory verwijdert terwijl de drop-in achterblijft, 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 te laat worden geladen.

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, 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 een 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 relevant is bij het leegmaken: het legen van één index laat de andere ongemoeid. De plugin documenteert ook WP_REDIS_SELECTIVE_FLUSH, waarmee u alleen de sleutels verwijdert die overeenkomen met uw prefix in plaats van de gehele database; dit gaat echter ten koste van een scan-operatie.

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

Houd staging buiten 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 de drop-in staan. Dit is tevens de snelste manier om te controleren 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 deprecated en vervangt deze 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 vlak na een flush of een herstart betekent niets, omdat de cache nog gevuld moet worden. Laat het een normale dag met verkeer draaien.

Vergelijk uw getal 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 niet door een paginacache kan worden geserveerd.

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 vervolgens ingeschakeld. Dat verschil is uw resultaat.

Wanneer Redis WordPress trager maakt

Een volledige instantie met het verkeerde beleid is de belangrijkste oorzaak, zoals hierboven beschreven: OOM command not allowed when used memory > 'maxmemory'. in het logboek, waarbij een site zowel voor de database als 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.

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

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, waardoor een oudere query die alleen op 'yes' filtert, op een moderne installatie een onvolledig beeld geeft. 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; een drop-in van een oudere plugin-versie in combinatie met een nieuwere plugin is namelijk een veelvoorkomende bron van onvoorspelbaar gedrag. Monitor een actieve server met redis-cli --stat, dat per seconde één regel uitvoert. redis-cli monitor toont elke opdracht en verbruikt aanzienlijke CPU-capaciteit op een drukke instantie; gebruik dit daarom slechts enkele seconden om een probleem te reproduceren en stop het daarna direct.

Nog één cijfer dat relevant is: redis-cli info clients rapporteert connected_clients. PHP-FPM houdt één verbinding per worker vast, dus dat getal moet in lijn zijn met uw pm.max_children en deze niet met een factor tien overschrijden. Als dit wel gebeurt, worden er verbindingen geopend die niet correct 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 belastend is dan het draaien van WordPress met een warme object cache. De object cache verwerkt de verzoeken die een page cache moet overslaan: ingelogde gebruikers, winkelwagentjes, 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 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 maxmemory van 256 MB is een ruimhartig begin op een server met 4 GB RAM.

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 bovendien een nutteloze Redis round-trip uitvoert. 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 round-trips per verzoek oplopen, 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 unieke WP_REDIS_PREFIX zodat sleutelnamen niet kunnen botsen, en een aparte WP_REDIS_DATABASE-index zodat het legen van de cache van de ene site niet de andere leegt. Wat ze wel delen is het geheugen: maxmemory en eviction gelden voor de gehele instantie, waardoor een drukke site de sleutels van een rustige site kan verwijderen. Sites die elkaar niet mogen beïnvloeden, hebben aparte Redis-instanties nodig met eigen limieten.

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

Ja. Dit is een drop-in, geen onderdeel van de WordPress-kern. 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 noodmaatregel als Redis offline is of niet naar behoren functioneert en u het admin-paneel niet kunt bereiken.