Redis per WordPress su VPS: configurazione e verifica

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 include già 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’implementazione che comunica con Redis, così la cache resta disponibile tra una richiesta e l’altra.

La memorizzazione nella cache degli oggetti non equivale alla cache delle pagine. Questa differenza determina se vale la pena seguire questa guida. Una cache delle pagine memorizza l’HTML già generato per un URL e lo restituisce 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 accede, aggiunge un articolo al carrello o apre l’area di amministrazione, la cache delle pagine non viene più utilizzata e WordPress elabora l’intera richiesta: bootstrap, plugin e query. Una cache degli oggetti rende più economica quella richiesta. È lo strumento adatto per il traffico che la cache delle pagine non può gestire: sessioni di utenti autenticati, carrelli, checkout e wp-admin. In un negozio WooCommerce, si tratta della maggior parte del traffico più oneroso.

Le due cache possono essere utilizzate insieme e, su un sito molto trafficato, sono entrambe utili. È importante identificare con precisione il problema da risolvere. Un sito vetrina con visitatori anonimi ottiene quasi tutti i vantaggi prestazionali da una cache delle pagine; aggiungere Redis modifica ben poco.

Prima di iniziare, considera un limite importante. Una cache degli oggetti non rende più veloce una query lenta. Elimina le ripetizioni di una query già eseguita. La prima richiesta dopo un cache miss deve sostenere il costo completo, quindi un plugin che esegue una query senza indice continuerà a eseguirla una volta per ogni durata della cache.

Cosa serve prima

• Un VPS Linux con una shell e sudo. Non è richiesto 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 ha un equivalente nell'interfaccia di amministrazione, ma la versione da shell è più rapida.
• Redis sulla stessa macchina di PHP. La latenza è l'obiettivo principale e un passaggio di rete annulla il vantaggio.

I comandi riportati di seguito sono pensati per Ubuntu 24.04 con PHP 8.3 e l'utente web www-data. Adattare la versione di PHP e l'utente alla configurazione del 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 distribuita tramite PECL. È più veloce di Predis, che è realizzato interamente in PHP, e il plugin la utilizza automaticamente quando è disponibile. PHP-FPM carica le estensioni all'avvio. Una nuova estensione diventa quindi disponibile solo dopo il riavvio del 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, mentre FPM può caricare un insieme diverso. Il controllo determinante è quello eseguito dalla diagnostica del plugin, più avanti.

Ad agosto 2026, Ubuntu 24.04 include Redis 7.0.15, una versione adeguata per una cache di oggetti. Per utilizzare invece una versione più recente, si può usare il repository APT ufficiale di Redis.

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 tutte le istruzioni seguenti restano valide senza modifiche.

Associare Redis all'interfaccia corretta per impedirne l'accesso dall'esterno

Per impostazione predefinita, Redis non usa una password. Qualsiasi host 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. Per questo la configurazione di rete viene prima dell'ottimizzazione.

Apri /etc/redis/redis.conf e verifica che contenga queste righe:

bind 127.0.0.1 -::1
protected-mode yes

Controlla quindi cosa è effettivamente in ascolto. Il file di configurazione esprime un'impostazione, mentre ss mostra la situazione reale.

sudo ss -lntp | grep 6379

127.0.0.1:6379 indica la configurazione corretta. 0.0.0.0:6379 significa che Redis risponde sull'interfaccia pubblica: correggi la riga bind e riavvia il servizio.

Quando PHP e Redis si trovano sullo stesso server, è preferibile usare un socket Unix rispetto a TCP su loopback. In questo modo non viene utilizzato lo stack TCP e l'accesso è regolato dai permessi del file, invece che da una regola del firewall che potresti modificare in seguito.

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

Il socket appartiene all'utente e al gruppo redis. L'utente del web server deve quindi 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

Il comando deve stampare anche PONG. Could not connect to Redis at /run/redis/redis-server.sock: Permission denied significa che il gruppo non è stato applicato. Controlla id www-data e ricorda che un processo PHP-FPM già in esecuzione mantiene i gruppi disponibili al momento dell'avvio. Per questo il riavvio è incluso nell'elenco. Mantieni TCP abilitato finché non hai verificato il funzionamento del socket. In caso contrario, un errore di battitura potrebbe disabilitare entrambi i percorsi contemporaneamente.

Quanta memoria assegnare a Redis?

Ricava il numero dal tuo server. Redis senza maxmemory 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 si tratta di MySQL. journalctl -k | grep -i "out of memory" mostra l’uccisione a posteriori, quando il sito è già irraggiungibile.

Parti dalla RAM totale e sottrai le altre esigenze. MySQL o MariaDB riserva innodb_buffer_pool_size, oltre ai buffer per ogni connessione. PHP-FPM utilizza pm.max_children moltiplicato per la dimensione residente effettiva di un singolo worker, comunemente da 64 MB a 128 MB su un sito con molti plugin. Il kernel e il web server richiedono alcune centinaia di megabyte. Quello che resta è il tuo limite massimo e Redis ne riceve una parte.

Ora misura invece di procedere per tentativi. Dopo un giorno di traffico reale:

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

Se used_memory_human resta molto al di sotto del limite, riduci il limite e assegna la RAM restituita a MySQL, che la utilizzerà meglio. Se raggiunge il limite e evicted_keys cresce per tutta la giornata, aumentalo. Imposta il valore in /etc/redis/redis.conf.

maxmemory 256mb
maxmemory-policy allkeys-lru

redis-cli config set maxmemory 256mb applica la modifica immediatamente e viene perso al riavvio successivo. È lo stesso problema di un semplice sysctl -w. Modifica il file, quindi sudo systemctl restart redis-server e leggi nuovamente il valore. È utile impostare anche un secondo limite: un limite MemoryMax sull’unità systemd impedisce a un 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 accanto a WordPress, lo stesso valore deve essere inserito in i limiti di memoria nel file Compose e lo stesso ragionamento guida la scelta di eseguire il database in Docker o sull’host.

Scegliere consapevolmente la policy di eviction

Una nuova istanza 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 le scritture e restituisce questo errore:

(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 nella richiesta successiva e fallisce nuovamente. Il sito deve quindi eseguire tutto il lavoro originale sul database, oltre a un round trip verso Redis per ogni chiave. Nell'amministrazione di WordPress non c'è alcuna indicazione di questo problema. La stringa compare nel log degli errori PHP: quando un sito rallenta dopo l'aggiunta di una cache, cerca OOM command not allowed con grep.

allkeys-lru è il valore predefinito corretto in questo caso. Quando la memoria è insufficiente, Redis elimina la chiave meno utilizzata di recente. È esattamente il comportamento desiderato per una object cache, perché ogni valore contiene una copia di dati ancora presenti in MySQL. La perdita di una chiave comporta una query. Il rifiuto di una scrittura comporta tutte le query, a ogni richiesta, finché qualcuno non rileva il problema.

Per questo utilizzo, 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 su una object cache può riempire l'istanza e iniziare a rifiutare le scritture. allkeys-lfu è un'alternativa valida se il traffico accede molto spesso a un insieme ridotto di chiavi, perché esegue l'eviction in base alla frequenza anziché alla recenza. Scegli una policy in modo consapevole e annota il motivo.

Persistenza: disabilitala se non hai un motivo per mantenerla

Il redis.conf fornito nel 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, mentre una cache ripristinata da un file vecchio di venti minuti contiene valori obsoleti che WordPress utilizzerà.

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

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

All'avvio viene spesso visualizzato anche questo avviso. Redis segnala che il fork potrebbe non riuscire in seguito:

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

Per disabilitare gli snapshot, imposta una pianificazione save vuota in /etc/redis/redis.conf, riavvia il servizio e verifica che il valore sia nuovamente vuoto.

save ""

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

Mantieni la persistenza solo se la stessa istanza contiene dati che non puoi ricreare, ad esempio una coda di job o contatori per il rate limiting. In questo caso, separa i due utilizzi. 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ù semplice.

Installa il plugin e comprendi 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 realtà copia wp-content/plugins/redis-cache/includes/object-cache.php in wp-content/object-cache.php. Questa copia è il drop-in, ed è il componente che esegue il lavoro. WordPress carica wp-content/object-cache.php molto presto, prima dell'esecuzione del codice di qualsiasi plugin. In questo modo la cache è disponibile per l'intera richiesta. Un plugin attivo senza un drop-in presente non memorizza nulla nella cache.

I messaggi di errore indicano quale delle due fasi non è riuscita. Object cache could not be enabled. significa che la copia non è riuscita, quindi wp-content non è 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 soluzione è 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, copia il file manualmente e assegnalo 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. e cancella il file. Se elimini la directory del plugin lasciando il drop-in, il sito continua a eseguire il vecchio codice della cache, senza un plugin che possa aggiornarlo.

Impostazioni di connessione in wp-config.php

Aggiungile prima della riga che contiene /* That's all, stop editing! */, perché le costanti definite dopo sono dichiarate 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'età di un valore memorizzato nella cache.

Un Redis, più siti: prefissi e database

Per impostazione predefinita, Redis fornisce 16 database numerati, ciascuno con un unico keyspace piatto. Due installazioni di 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 per generare le proprie pagine. Assegna 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 i keyspace, un aspetto importante durante il flush: lo svuotamento di un indice non modifica gli altri. Il plugin documenta inoltre WP_REDIS_SELECTIVE_FLUSH, che elimina soltanto le chiavi corrispondenti al tuo prefisso invece dell'intero database, ma deve prima individuarle tramite una scansione.

Prefissi e indici non separano la memoria. maxmemory e la eviction policy si applicano all'intera istanza. Di conseguenza, un sito molto attivo può causare l'espulsione delle 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 punti 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 alcun deploy e senza lasciare traccia.

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

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

Meglio ancora, assegna allo staging un'istanza Redis separata oppure disabilita completamente la object cache. define( 'WP_REDIS_DISABLED', true ); disattiva la cache a runtime e lascia il drop-in al suo posto. È 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.

Verifica, non fidarti

Inizia dagli strumenti diagnostici del plugin.

wp redis status

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

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

wp eval 'var_dump( wp_using_ext_object_cache() );'

bool(true) indica che il core sta comunicando con una cache di oggetti esterna.

Quindi verifica 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 evidenti oppure che il prefisso non è quello previsto.

Infine, controlla le metriche raccolte da Redis.

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

Il rapporto di hit è keyspace_hits / (keyspace_hits + keyspace_misses) e la documentazione di Redis fornisce questa formula. Interpretalo 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 uno svuotamento o un riavvio non è significativo, perché la cache si sta ancora popolando. Lascialo funzionare per una normale giornata di traffico.

Non confrontare il tuo valore con un hit rate o con un numero di query pubblicato da un'azienda di hosting. Quei dati descrivono i loro siti e il loro insieme di plugin. Il dato importante è 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, diverse volte, con la cache disattivata (WP_REDIS_DISABLED) e poi attivata. Questa differenza è il risultato.

Quando Redis rallenta WordPress

Un'istanza piena con una policy errata è il problema principale, già descritto sopra: OOM command not allowed when used memory > 'maxmemory'. nei log e il sito che sostiene i costi sia del database sia 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 richiede 1 ms, si accumula mezzo secondo di attesa che un socket locale non introdurrebbe. Mantieni Redis sullo stesso server oppure su una rete privata con una latenza inferiore a un millisecondo.

Una tabella delle opzioni autoloaded molto grande è il terzo problema ed è comune nei siti datati. WordPress memorizza tutte le opzioni autoloaded come un'unica chiave, quindi a ogni richiesta viene trasferito 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 precedente che cerca soltanto 'yes' restituisce valori inferiori al reale su un'installazione moderna. Un valore superiore a un megabyte indica un problema da correggere nella tabella delle opzioni, non in Redis.

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

Pulizia

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 può causare comportamenti anomali. Monitora un server in produzione con redis-cli --stat, che stampa una riga al secondo. redis-cli monitor stampa ogni comando e può consumare una quantità significativa di CPU su un’istanza sotto carico; usalo per alcuni secondi mentre riproduci il problema, quindi interrompilo.

C’è un ultimo valore che conviene conoscere: redis-cli info clients restituisce connected_clients. PHP-FPM mantiene una connessione per ogni worker, quindi questo valore dovrebbe essere proporzionato a pm.max_children, non superarlo di un ordine di grandezza. In caso contrario, un componente sta aprendo 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 memorizzato senza eseguire PHP, 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 aree riservate conviene usare 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?

Calcola il valore in base al tuo server invece di copiare un numero predefinito. Prendi la 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, quindi controlla used_memory_human in redis-cli info memory dopo una giornata di traffico e adatta il valore. Un singolo sito WordPress utilizza in genere alcune decine di megabyte, quindi un maxmemory da 256 MB è un punto di partenza prudente su un server con 4 GB.

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

La causa abituale è 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 aggiunge un round trip Redis inutile. 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, che attraversa la 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 distinto, 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 trafficato può espellere le chiavi di un sito poco utilizzato. I siti che non devono influenzarsi a vicenda richiedono istanze Redis separate, con limiti indipendenti.

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

Sì. È un drop-in e non fa parte del core di WordPress; rimuoverlo riporta WordPress alla cache integrata per richiesta. Il sito continua a funzionare, ma esegue semplicemente più query al database. Preferisci wp redis disable, che elimina il file correttamente e restituisce Object cache disabled.. Eliminarlo manualmente è la procedura di emergenza appropriata se Redis non è disponibile o non funziona correttamente e non puoi accedere all'area di amministrazione.