Redis come cache oggetti WordPress su un VPS

Che cosa fa una cache degli oggetti Redis per WordPress

Una cache degli oggetti Redis per WordPress memorizza in memoria i risultati delle query al database, così la richiesta successiva li legge da Redis invece di interrogare nuovamente MySQL. WordPress dispone già di una cache degli oggetti nel core, WP_Object_Cache, ma questa risiede nella memoria PHP e viene eliminata al termine della richiesta. Un file drop-in la sostituisce con un componente che comunica con Redis, così la cache rimane disponibile da una richiesta all'altra.

La cache degli oggetti non è una cache delle pagine, e questa differenza determina se questa guida è utile nel tuo caso. Una cache delle pagine memorizza l'HTML completo di un URL e lo serve nuovamente senza eseguire PHP. È più veloce di qualsiasi soluzione basata su Redis e funziona per i visitatori che non hanno effettuato l'accesso. Quando un utente effettua l'accesso, aggiunge un prodotto al carrello o apre l'area di amministrazione, la cache delle pagine non può più intervenire e WordPress esegue l'intera richiesta: bootstrap, plugin e query. Una cache degli oggetti rende più economica quella richiesta. È lo strumento adatto al traffico che una cache delle pagine non può gestire: sessioni degli utenti autenticati, carrelli, checkout e wp-admin. In un negozio WooCommerce, si tratta della maggior parte del traffico più costoso da elaborare.

Le due cache possono essere usate insieme e, su un sito con molto traffico, sono entrambe utili. Devi identificare con precisione il problema che vuoi risolvere. Un sito vetrina con visitatori anonimi ottiene quasi tutti i vantaggi prestazionali da una cache delle pagine, quindi aggiungere Redis cambia ben poco.

Prima di iniziare, considera un limite importante. Una cache degli oggetti non rende veloce una query lenta. Evita di ripetere una query già eseguita. La prima richiesta dopo un'assenza nella cache paga il costo completo, quindi un plugin che esegue una query senza indice continua a eseguirla una volta per ogni durata della cache.

Prerequisiti

• Un VPS Linux con una shell e sudo. Non è necessario alcun pannello di controllo.
• WordPress servito da PHP-FPM, ad esempio uno stack LAMP su Ubuntu 24.04.
• WP-CLI installato sul server. Ogni passaggio descritto qui ha un equivalente nell'interfaccia di amministrazione, ma la versione da shell è più rapida.
• Redis sulla stessa macchina di PHP. La bassa latenza è l'obiettivo principale e un passaggio di rete la annulla.

I comandi seguenti sono scritti per Ubuntu 24.04 con PHP 8.3 e l'utente web www-data. Adattare la versione di PHP e l'utente al proprio server. Eseguire i comandi wp dalla directory di WordPress, quella che contiene wp-config.php.

Installare Redis e l'estensione PHP

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

redis-cli ping dovrebbe restituire PONG. Se restituisce Could not connect to Redis at 127.0.0.1:6379: Connection refused, il server non è in esecuzione. Consultare systemctl status redis-server prima di procedere.

php-redis è PhpRedis, l'estensione C di PECL. È più veloce di Predis, che è scritta interamente in PHP, e il plugin la usa automaticamente quando è disponibile. PHP-FPM carica le estensioni all'avvio. Una nuova estensione non è disponibile finché non si riavvia il pool.

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

Prestare attenzione all'ultimo controllo: php -m elenca i moduli del PHP della riga di comando e PHP-FPM può caricare un insieme diverso. Il controllo valido è quello della diagnostica del plugin, riportata più avanti.

Ad agosto 2026, Ubuntu 24.04 distribuisce Redis 7.0.15, una versione adeguata per una cache di oggetti. Se si desidera una release più recente, Redis pubblica un proprio repository APT.

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

Se la distribuzione include Valkey, il fork avviato dopo la modifica della licenza del 2024, il protocollo è lo stesso e tutto quanto segue si applica senza modifiche.

Associare Redis a un'interfaccia per impedirne l'accesso dall'esterno

Per impostazione predefinita, Redis non richiede una password. Qualsiasi client in grado di aprire una connessione alla porta 6379 può leggere tutti i valori memorizzati nella cache ed eseguire FLUSHALL. Le istanze esposte a Internet vengono individuate dagli scanner nel giro di poche ore, quindi la configurazione di rete viene prima dell'ottimizzazione.

Aprire /etc/redis/redis.conf e verificare che contenga queste righe:

bind 127.0.0.1 -::1
protected-mode yes

Controllare quindi cosa è realmente in ascolto, perché il file di configurazione esprime un'impostazione, mentre ss fornisce la verifica effettiva.

sudo ss -lntp | grep 6379

127.0.0.1:6379 è il risultato desiderato. 0.0.0.0:6379 indica che Redis risponde sull'interfaccia pubblica: correggere la riga bind e riavviare il servizio.

Quando PHP e Redis si trovano sullo stesso server, è preferibile usare un socket Unix invece del protocollo TCP tramite loopback. In questo modo non viene attraversato lo stack TCP e l'accesso viene determinato dai permessi del file, anziché da una regola del firewall che potrebbe essere modificata in seguito.

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

Il socket appartiene all'utente e al gruppo redis, quindi l'utente del web server deve essere aggiunto a quel gruppo.

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

Deve inoltre essere visualizzato PONG. Could not connect to Redis at /run/redis/redis-server.sock: Permission denied indica che il gruppo non è stato applicato. Controllare id www-data e ricordare che un processo PHP-FPM già in esecuzione conserva i gruppi disponibili al momento dell'avvio; per questo il riavvio è incluso nell'elenco. Lasciare TCP abilitato finché il socket non è stato verificato, altrimenti un errore di battitura potrebbe rendere non disponibili entrambi i percorsi.

Quanta memoria deve avere Redis?

Ricava il valore dal tuo server. Senza maxmemory, Redis continua a crescere finché il kernel esaurisce la memoria e l’OOM killer termina un processo, di solito quello più grande. Su un server WordPress, spesso è MySQL. journalctl -k | grep -i "out of memory" mostra l’evento dopo che si è verificato, ma a quel punto il sito è già inattivo.

Parti dalla RAM totale e sottrai le altre esigenze. MySQL o MariaDB riserva innodb_buffer_pool_size, oltre ai buffer per le singole connessioni. PHP-FPM usa pm.max_children moltiplicato per la dimensione residente effettiva di un worker; su un sito con molti plugin, il valore è spesso compreso tra 64 MB e 128 MB. Il kernel e il web server richiedono alcune centinaia di megabyte. La memoria rimanente è il tuo limite massimo e Redis ne riceve una parte.

Ora misura invece di procedere per tentativi. Dopo una giornata di traffico reale:

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

Se used_memory_human rimane molto al di sotto del limite, riduci il limite e restituisci la RAM a MySQL, che la utilizzerà meglio. Se raggiunge il limite e evicted_keys aumenta per tutta la giornata, alzalo. Imposta il valore in /etc/redis/redis.conf.

maxmemory 256mb
maxmemory-policy allkeys-lru

redis-cli config set maxmemory 256mb si applica immediatamente e viene perso al riavvio successivo, come accade con un semplice sysctl -w. Modifica il file, quindi esegui sudo systemctl restart redis-server e leggi nuovamente il valore. È utile impostare anche un secondo limite: un limite MemoryMax sull’unità systemd impedisce a Redis configurato in modo errato di rendere indisponibile il server. Impostalo al di sopra di maxmemory, mai allo stesso valore, perché un limite cgroup termina il processo invece di espellere una chiave. Se Redis viene eseguito in un container insieme a WordPress, lo stesso valore va indicato nei limiti di memoria del file Compose e lo stesso ragionamento guida la scelta tra eseguire il database in Docker o sull’host.

Scegliere consapevolmente la policy di eviction

Una nuova installazione di Redis usa per impostazione predefinita noeviction. Verifica la configurazione in uso:

redis-cli config get maxmemory-policy

Con noeviction, un'istanza piena smette di accettare scritture e restituisce questo messaggio:

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

Questa è la modalità di errore peggiore descritta nella guida, perché il sito non diventa irraggiungibile. Diventa più lento. Ogni scrittura nella cache fallisce, quindi WordPress torna al database per recuperare il valore, poi prova a memorizzarlo di nuovo alla richiesta successiva e fallisce ancora. Il sito esegue quindi tutte le operazioni originali sul database, più un round trip verso Redis per ogni chiave. Nell'amministrazione di WordPress non compare alcuna indicazione di questo problema. La stringa viene registrata nel log degli errori PHP: quando un sito rallenta dopo l'aggiunta di una cache, cerca OOM command not allowed con grep.

allkeys-lru è l'impostazione predefinita corretta in questo caso. Quando la memoria è insufficiente, Redis rimuove la chiave utilizzata meno di recente. È esattamente il comportamento desiderato per una object cache, perché ogni valore contiene una copia di dati che esistono ancora in MySQL. La perdita di una chiave costa una query. Rifiutare una scrittura costa tutte le query, a ogni richiesta, finché qualcuno non rileva il problema.

Per questo caso, evita le policy volatile-*. Considerano soltanto le chiavi con una scadenza e Redis documenta che, quando nessuna chiave ha una scadenza, si comportano come noeviction. WordPress memorizza la maggior parte delle voci della object cache senza TTL, quindi volatile-lru in una object cache può riempire l'istanza e iniziare a rifiutare le scritture. allkeys-lfu è un'alternativa valida se il traffico utilizza molto spesso un insieme ridotto di chiavi, perché rimuove le chiavi in base alla frequenza anziché alla recenza. Scegli una policy in modo consapevole e annota il motivo.

Persistenza: disabilitatela se non avete un motivo per mantenerla

Il redis.conf fornito con il pacchetto abilita gli snapshot RDB con righe come save 900 1 e lascia disabilitato il file append-only. Per una cache di oggetti pura, gli snapshot non offrono alcun vantaggio. Per definizione, i dati possono essere rigenerati e una cache ripristinata da un file vecchio di venti minuti contiene valori obsoleti che WordPress utilizzerà comunque.

Gli snapshot hanno anche un costo. BGSAVE crea un fork del processo e il meccanismo copy-on-write può far aumentare rapidamente l'uso della memoria mentre il processo figlio scrive. Su un VPS di piccole dimensioni, questo compare nel log di Redis:

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

Spesso all'avvio compare anche questo avviso, con cui Redis indica che in seguito il fork potrebbe non riuscire:

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

Per disabilitare gli snapshot, impostate una pianificazione save vuota in /etc/redis/redis.conf, riavviate il servizio e verificate che il valore sia nuovamente vuoto.

save ""

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

Mantenete la persistenza solo se la stessa istanza contiene dati che non potete ricostruire, ad esempio una coda di job o contatori per il rate limiting. In questo caso, separate i due carichi. Una cache deve poter espellere le chiavi, mentre i dati persistenti devono conservarle; maxmemory e l'eviction si applicano all'intera istanza, non a un singolo indice di database. Due istanze su due socket sono la soluzione più pulita.

Installare il plugin e capire il drop-in

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

wp redis enable stampa Object cache enabled. in caso di successo. In pratica, copia wp-content/plugins/redis-cache/includes/object-cache.php in wp-content/object-cache.php. Questa copia è il drop-in, che contiene la logica effettivamente utilizzata. WordPress carica wp-content/object-cache.php molto presto, prima dell'esecuzione del codice dei plugin. In questo modo la cache è disponibile per l'intera richiesta. Un plugin attivo senza il relativo drop-in non memorizza nulla nella cache.

I messaggi di errore indicano quale delle due operazioni non è riuscita. Object cache could not be enabled. significa che la copia non è riuscita. wp-content non è quindi scrivibile dall'utente che esegue WP-CLI. A foreign object cache drop-in was found. significa che un altro plugin di caching utilizza già quel nome file. La correzione consiste nell'eseguire wp redis update-dropin. Un messaggio che termina con Redis server is unreachable:, seguito dall'errore del client, indica che le impostazioni di connessione non sono corrette. Torna quindi a redis-cli ping.

Se la copia non è riuscita a causa dei permessi, copiala manualmente e assegna il file all'utente del web server.

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

La rimozione del plugin non rimuove il drop-in. Esegui prima wp redis disable: stampa Object cache disabled. ed elimina il file. Se elimini la directory del plugin lasciando il drop-in, il sito continuerà a utilizzare il vecchio codice della cache, ma senza un plugin che possa aggiornarlo.

Impostazioni di connessione in wp-config.php

Aggiungile sopra la riga /* That's all, stop editing! */, perché le costanti definite dopo quella riga vengono elaborate troppo tardi.

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

Per il socket Unix, imposta lo schema e il percorso. Host e porta vengono quindi ignorati.

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

WP_REDIS_MAXTTL impone una scadenza per ogni chiave, espressa in secondi. Non è necessario con allkeys-lru ed è utile se vuoi imporre un limite massimo all'anzianità di un valore memorizzato nella cache.

Un Redis, più siti: prefissi e database

Redis fornisce per impostazione predefinita sedici database numerati e uno spazio dei nomi delle chiavi piatto all'interno di ciascuno. Due installazioni WordPress configurate per usare il database 0 senza prefisso scrivono gli stessi nomi di chiave nello stesso spazio. Di conseguenza, un sito può leggere le opzioni dell'altro e utilizzarle nelle proprie risposte. Assegnate a ogni sito un prefisso distinto.

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

Il prefisso separa i nomi delle chiavi. L'indice del database separa gli spazi dei nomi, cosa importante durante il flush: lo svuotamento di un indice non modifica gli altri. Il plugin documenta anche WP_REDIS_SELECTIVE_FLUSH, che elimina soltanto le chiavi corrispondenti al prefisso, invece dell'intero database, ma deve prima individuarle tramite una scansione.

Prefissi e indici non separano la memoria. maxmemory e la policy di eviction si applicano all'intera istanza. Di conseguenza, un sito molto attivo può espellere le chiavi di un sito inattivo, senza che nessuno dei due lo segnali. I siti che non devono influenzarsi a vicenda richiedono istanze Redis separate, ciascuna con il proprio socket e il proprio limite.

Mantieni lo staging fuori dalla cache di produzione

Un sito di staging è in genere una copia dei file e del database di produzione. Questo significa che è una copia di wp-config.php, con lo stesso prefisso e lo stesso indice del database. Se lo colleghi allo stesso Redis, scrive le chiavi di produzione con i valori dello staging. Un prezzo di test o un'opzione modificata può quindi comparire sul sito live senza un deploy e senza lasciare tracce.

Imposta manualmente un salt distinto per ogni ambiente. In wp-config.php dello staging:

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

È preferibile assegnare allo staging un'istanza Redis dedicata oppure non usare affatto una cache degli oggetti. define( 'WP_REDIS_DISABLED', true ); disattiva la cache a runtime e lascia il drop-in installato. È anche il modo più rapido per verificare se un bug dipende dalla cache.

I tutorial meno recenti impostano WP_CACHE_KEY_SALT per questo scopo. Il readme del plugin indica che questa costante è deprecata e sostituita da WP_REDIS_PREFIX. Usa quindi il nuovo nome.

Verificalo invece di fidarti

Inizia con la diagnostica integrata del plugin.

wp redis status

La riga più importante è Drop-in. Drop-in: Valid significa che WordPress sta caricando il file di questo plugin. Drop-in: Not installed significa che la copia non è mai stata eseguita e che il sito non dispone di una cache persistente, anche se la schermata di amministrazione appare corretta. Status segnala la connessione e Client indica l'estensione in uso: qui devi verificare che sia PhpRedis e non Predis.

Poi interroga direttamente il core di WordPress, perché non dipende da ciò che ritiene il plugin.

wp eval 'var_dump( wp_using_ext_object_cache() );'

bool(true) significa che il core comunica con una cache di oggetti esterna.

Verifica quindi che le chiavi arrivino, usando il prefisso configurato.

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

L'aumento di dbsize mentre navighi nel sito è la prova. Zero chiavi con un drop-in valido significa che la connessione sta fallendo senza messaggi oppure che il prefisso non è quello previsto.

Infine, controlla le metriche che Redis raccoglie.

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

La percentuale di hit è keyspace_hits / (keyspace_hits + keyspace_misses) e la documentazione di Redis fornisce questa formula. Interpretala tenendo presenti due aspetti. I contatori coprono l'intera istanza dall'ultimo riavvio, quindi combinano tutti i siti e tutte le applicazioni che la condividono. Inoltre, il rapporto subito dopo un flush o un riavvio non è significativo, perché la cache si sta ancora popolando. Lasciala funzionare per una normale giornata di traffico.

Non confrontare il tuo valore con una percentuale di hit o un conteggio delle query pubblicato da un provider di hosting. Quei dati descrivono i suoi siti e il suo insieme di plugin. Il dato rilevante è il tuo, misurato prima e dopo su una pagina che una page cache non può servire.

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

Esegui il test con un cookie jar autenticato, più volte, prima con la cache disattivata (WP_REDIS_DISABLED) e poi con la cache attivata. La differenza è il risultato.

Quando Redis rallenta WordPress

Un'istanza piena con la policy errata è il problema principale, già descritto sopra: OOM command not allowed when used memory > 'maxmemory'. nei log e un sito che paga sia il costo del database sia quello della cache.

Redis su un altro host è il secondo problema. WordPress esegue centinaia di chiamate alla object cache durante una singola richiesta. Se una richiesta esegue 500 chiamate e ogni round trip costa 1 ms, si accumula mezzo secondo di attesa che un socket locale non avrebbe. Mantieni Redis sullo stesso server oppure su una rete privata con latenza inferiore a 1 ms. Il vantaggio effettivo del kernel nel caso dello stesso server è una questione distinta: la pianificazione cache-aware aggiunta in Linux 7.2 cerca di mantenere processi che comunicano frequentemente, come PHP-FPM e Redis, su core che condividono una cache; una macchina virtuale VPS beneficia di questa caratteristica meno di un server bare metal.

Una tabella enorme di opzioni caricate automaticamente è il terzo problema, comune nei siti meno recenti. WordPress memorizza tutte le opzioni autoloaded come un'unica chiave, quindi ogni richiesta trasferisce sulla connessione un megabyte di dati. Misurala:

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 ha aggiunto nuovi valori per l'autoload, quindi una query meno recente che cerca soltanto 'yes' restituisce valori inferiori al reale su un'installazione moderna. Se la dimensione supera 1 megabyte, il problema va risolto nella tabella delle opzioni, non in Redis.

Un riavvio svuota tutto, quindi i minuti successivi a systemctl restart redis-server contengono solo cache miss e attività sul database. Riavvia quando il traffico è basso. Inoltre, una object cache non impedisce l'esecuzione di wp-cron.php durante il caricamento delle pagine da parte dei visitatori, che è un'altra causa di richieste lente: sposta WP-Cron in un vero job cron di sistema mentre esegui queste modifiche.

Manutenzione

Esegui il flush dopo un deploy che modifica le opzioni o il codice del tema con wp cache flush. Esegui wp redis update-dropin dopo l'aggiornamento di un plugin se il drop-in non si è aggiornato automaticamente, perché un drop-in di una versione precedente del plugin usato con una versione più recente è una causa concreta di comportamenti anomali. Monitora un server in produzione con redis-cli --stat, che visualizza una riga al secondo. redis-cli monitor visualizza ogni comando e consuma CPU in modo significativo su un'istanza sotto carico. Usalo quindi per alcuni secondi mentre riproduci il problema, poi interrompilo.

È utile conoscere anche un ultimo valore: redis-cli info clients restituisce connected_clients. PHP-FPM mantiene una connessione per ogni worker, quindi questo valore dovrebbe essere in linea con pm.max_children, non superarlo di un ordine di grandezza. Se lo supera, significa che qualcosa apre connessioni senza chiuderle.

FAQ

Mi serve ancora una page cache se utilizzo una object cache Redis?

Sì, per il traffico anonimo. Una page cache restituisce HTML già archiviato senza eseguire PHP, un'operazione sempre meno costosa rispetto all'esecuzione di WordPress con una object cache già popolata. La object cache gestisce le richieste che una page cache deve escludere: utenti autenticati, carrelli, checkout e wp-admin. In un negozio online o in un sito con area riservata conviene utilizzare entrambe. In un sito i cui visitatori non effettuano mai l'accesso, la page cache svolge quasi tutto il lavoro.

Quanta memoria devo assegnare a Redis per WordPress?

Calcolala in base al tuo server, invece di copiare un valore predefinito. Parti dalla RAM totale, sottrai il buffer pool di MySQL e i buffer per connessione, sottrai pm.max_children moltiplicato per la dimensione residente di un worker PHP-FPM, quindi sottrai alcune centinaia di megabyte per il kernel e il web server. Assegna a Redis una parte della memoria rimanente, poi controlla used_memory_human in redis-cli info memory dopo una giornata di traffico e modifica il valore se necessario. Un singolo sito WordPress si stabilizza di solito su alcune decine di megabyte, quindi un maxmemory da 256 MB è un punto di partenza generoso su un server con 4 GB di RAM.

Perché il mio sito è diventato più lento dopo l'abilitazione della object cache Redis?

La causa più comune è un'istanza piena che utilizza la policy noeviction. Redis rifiuta le nuove scritture e restituisce OOM command not allowed when used memory > 'maxmemory'., quindi WordPress ricorre al database per ogni valore e, in più, sostiene il costo inutile di un round trip verso Redis. Controlla redis-cli config get maxmemory-policy, imposta allkeys-lru e verifica che maxmemory non sia troppo piccolo. Altre cause comuni sono un server Redis su un host remoto, dove centinaia di round trip per richiesta si sommano, e un valore di opzioni autocaricate di diversi megabyte, trasferito sulla connessione a ogni richiesta.

Più siti WordPress possono condividere un server Redis?

Sì, con le dovute precauzioni. Assegna a ogni sito un WP_REDIS_PREFIX univoco, in modo che i nomi delle chiavi non possano entrare in conflitto, e un indice WP_REDIS_DATABASE separato, così lo svuotamento della cache di un sito non svuota quella degli altri. La memoria resta condivisa: maxmemory e l'eviction si applicano all'intera istanza, quindi un sito molto attivo può espellere le chiavi di un sito poco attivo. I siti che non devono influenzarsi a vicenda richiedono istanze Redis separate, con limiti propri.

È sicuro eliminare wp-content/object-cache.php?

Sì. È un drop-in, non fa parte del core di WordPress, e la sua rimozione riporta WordPress alla cache integrata per richiesta. Il sito continua a funzionare, eseguendo semplicemente più query sul database. È preferibile usare wp redis disable, che elimina il file correttamente e segnala Object cache disabled.. L'eliminazione manuale è la soluzione di emergenza appropriata se Redis è inattivo o presenta problemi e non puoi accedere all'area di amministrazione.