Redis come cache per WordPress: quando serve e come verificare che funzioni

Redis come object cache per WordPress riduce le query a MySQL tenendo in memoria i risultati già calcolati. Ha senso su siti con traffico reale e con un server su cui si può installare un servizio in più. Su un hosting condiviso base, con poche centinaia di visite al giorno, spesso è solo un demone in più da tenere d'occhio senza benefici misurabili. Questa guida copre installazione, configurazione del plugin e il comando per capire se sta davvero facendo qualcosa.

Installazione di Redis su Ubuntu

Ubuntu include Redis nei repository ufficiali. Il pacchetto redis-tools porta anche redis-cli, che serve per le verifiche più avanti:

sudo apt update
sudo apt install redis-server redis-tools

Verifica che il servizio sia attivo:

sudo systemctl status redis-server

Chi vuole una versione più recente di quella pacchettizzata da Ubuntu può aggiungere il repository ufficiale Redis (pacchetto redis invece di redis-server), ma per un uso come cache di WordPress la versione di distribuzione è sufficiente nella maggior parte dei casi.

Configurare Redis come cache

Di default Redis non ha un limite di memoria impostato e non scarta automaticamente le chiavi vecchie. Per un uso come cache, la documentazione ufficiale di Redis indica una configurazione dedicata nel file redis.conf:

maxmemory 2mb
maxmemory-policy allkeys-lru

Il valore di maxmemory va adattato alla RAM disponibile sul server (2 MB è solo l'esempio della documentazione). Con allkeys-lru Redis scarta automaticamente le chiavi meno usate quando si raggiunge il limite, senza bisogno che l'applicazione imposti un TTL.

Il plugin di object cache per WordPress

Il plugin più diffuso è Redis Object Cache, disponibile su wordpress.org, sviluppato da Till Krüss. Il plugin supporta Predis, PhpRedis (PECL), Relay, replicazione, sentinel, clustering e WP-CLI.

Dopo l'installazione, da pannello si va su Impostazioni → Redis (o Network Admin → Impostazioni → Redis su multisito) per attivare la cache. Se la connessione automatica non funziona, il file ufficiale di installazione del plugin indica le costanti da aggiungere in wp-config.php, sopra la riga /* That's all, stop editing! */:

define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_PREFIX', 'nome-sito');
define('WP_REDIS_DATABASE', 0); // 0-15
define('WP_REDIS_TIMEOUT', 1);
define('WP_REDIS_READ_TIMEOUT', 1);

WP_REDIS_PREFIX e WP_REDIS_DATABASE servono quando più siti WordPress condividono la stessa istanza Redis: senza un prefisso o un numero di database diverso, lo svuotamento della cache di un sito cancella anche i dati degli altri.

Chi gestisce i plugin via Composer può usare gli equivalenti comandi WP-CLI:

composer require wpackagist-plugin/redis-cache
wp redis enable
wp redis status

Verificare che la cache stia funzionando: redis-cli

Il comando che conta è INFO stats, che restituisce fra l'altro due contatori cumulativi: keyspace_hits (chiavi trovate in cache) e keyspace_misses (chiavi richieste ma assenti). La documentazione ufficiale di Redis sull'eviction spiega come calcolare la percentuale di richieste soddisfatte dalla cache:

redis-cli INFO stats | grep -E "keyspace_hits|keyspace_misses"

keyspace_hits:38291847
keyspace_misses:4982731

La formula è:

keyspace_hits / (keyspace_hits + keyspace_misses) * 100

Un valore basso rispetto alle attese può segnalare una policy di eviction non adatta: in quel caso va controllato anche evicted_keys nello stesso output di INFO stats.

Per capire quante chiavi sono presenti e per quanto tempo restano vive, si usa:

redis-cli INFO keyspace

che restituisce una riga per database, del tipo db0:keys=42857,expires=41200,avg_ttl=3542. Se avg_ttl è molto basso rispetto a quanto ci si aspetta dal plugin, le chiavi scadono prima di essere riutilizzate e l'hit rate ne risente.

Per controllare quanta memoria sta usando Redis:

redis-cli INFO memory | grep used_memory_human

Un valore che cresce continuamente senza stabilizzarsi, con maxmemory-policy impostata correttamente, va controllato: può indicare chiavi senza scadenza che il plugin non sta gestendo come previsto.

Quando Redis non serve

Non ogni sito WordPress trae beneficio da un object cache esterno. I segnali che indicano che probabilmente non conviene installarlo:

• Traffico basso: se il sito riceve poche centinaia di visite al giorno, la cache delle pagine (anche solo quella del plugin di caching già installato) elimina gran parte delle query ripetute senza bisogno di un servizio in più da amministrare.
• Hosting condiviso senza accesso a Redis: su molti piani di hosting condiviso non c'è modo di installare o raggiungere un'istanza Redis, né di eseguire redis-cli. In questi casi la scelta pratica è un plugin di cache a livello di pagina (che non richiede demoni esterni) oppure il passaggio a un piano con accesso a servizi aggiuntivi.
• Sito statico o quasi: se i contenuti cambiano raramente, una cache di pagina con TTL lungo copre lo stesso problema che Redis risolverebbe a livello di query, con meno componenti da mantenere.

Prima di installare Redis vale la pena chiedersi se il collo di bottiglia è davvero nelle query ripetute al database. Se non si sa, la risposta è nei numeri di INFO stats dopo qualche giorno di attività: se l'hit rate resta vicino allo zero o il traffico non giustifica un demone in più, va disinstallato senza rimpianti.