Cache Redis per PrestaShop: configurazione e benefici sulle prestazioni

La maggior parte dei consigli sulle prestazioni di PrestaShop si ferma a "usa Redis" e ti lascia davanti a un menu a tendina del back office a chiederti cosa inserire nei quattro campi sotto. Questa guida è l'altra metà del lavoro: la configurazione concreta. Dove Redis si integra con PrestaShop, cosa si aspetta ogni campo in Advanced Parameters → Performance, come indirizzare le sessioni verso Redis (cosa che il back office non può fare per te), come verificare che stia davvero memorizzando in cache invece di ricadere silenziosamente sui file, e come leggere i numeri dopo la configurazione per capire se è servito. Se stai ancora decidendo se Redis valga la pena per il tuo negozio, parti dal caso d'uso spiegato in Redis per PrestaShop: il miglioramento delle prestazioni di cui il tuo negozio probabilmente ha bisogno, questo articolo dà per scontato che tu abbia già deciso e voglia farlo funzionare correttamente.

Rivisto per PrestaShop 1.6, 1.7, 8.x e 9.x. Usiamo Redis su mypresta.rocks. I compromessi descritti riflettono questa esperienza. Redis da solo non determina un punteggio PageSpeed: confronta l’intero negozio prima e dopo una modifica nelle stesse condizioni di test.

Cosa memorizza Redis nella cache di PrestaShop, e cosa no

La principale fonte di delusione con Redis su PrestaShop è aspettarsi che faccia qualcosa che non fa. Prima di tutto, una precisazione che orienta tutto il resto: PrestaShop 1.7/8 nativo non espone Redis come backend integrato per la cache degli oggetti nella pagina Performance. Le opzioni standard del caching system sono il filesystem e backend in stile Memcached (APC/APCu, XCache e Memcache/Memcached, a seconda della versione PHP e delle estensioni caricate). Redis diventa un'opzione qui solo quando un modulo o un backend cache personalizzato la aggiunge. Quando è disponibile, quell'impostazione governa esattamente una cosa: la cache degli oggetti interna di PrestaShop. È il livello della classe Cache, che memorizza elementi che altrimenti PrestaShop ricostruirebbe a ogni richiesta: configurazione serializzata, albero delle categorie, risultati di lookup ripetuti su ObjectModel, registrazioni degli hook dei moduli e strutture dati interne simili. Su una pagina con molte richieste queste letture avvengono decine di volte, e spostarle dal disco alla RAM è il punto da cui arriva il guadagno.

Non attiva la cache della pagina intera e non sposta le sessioni dei clienti in Redis. Sono due lavori distinti:

• Cache della pagina intera è un meccanismo completamente diverso: memorizza intere pagine HTML già renderizzate, così PHP viene eseguito pochissimo. PrestaShop non include una cache della pagina intera nativa; la aggiungi con un modulo o con un reverse proxy. È un tema a sé, trattato in PrestaShop cache: full-page cache modules explained. Redis può essere il backend di archiviazione su cui scrivono alcuni di quei moduli FPC, ma selezionare un backend Redis per la cache degli oggetti nella pagina Performance non ti dà la cache della pagina intera.
• Archiviazione delle sessioni in Redis si configura in PHP, non nel back office di PrestaShop (lo vediamo più sotto). L'impostazione Redis nella pagina Performance lascia le sessioni esattamente dov'erano: sul filesystem.

Quindi? Saperlo prima ti evita l'errore più comune con Redis: attivare l'interruttore nel back office, vedere un miglioramento modesto e concludere che "Redis non fa granché". Hai abilitato uno dei tre lavori possibili. Decidi consapevolmente quali vuoi, perché ognuno si configura in un punto diverso.

Prerequisiti: il lato server, in breve

Questa è una guida alla configurazione di PrestaShop, non un corso da amministratore di sistema Redis, quindi i passaggi lato server sono volutamente brevi, e sugli hosting PrestaShop gestiti spesso sono già stati eseguiti per te. Prima che PrestaShop possa usare Redis devono essere presenti due cose:

• Il server Redis stesso, raggiungibile dal server web (di solito su 127.0.0.1:6379 quando gira sulla stessa macchina). Verifica con redis-cli ping, un'installazione sana risponde PONG.
• L'estensione PHP redis, caricata nello stesso PHP che esegue il tuo negozio. Questo è il passaggio che molti saltano: un php -m | grep redis da CLI può mostrare l'estensione mentre il tuo pool PHP-FPM non ce l'ha, perché caricano file php.ini diversi. Controlla quello che conta guardando la pagina Advanced Parameters → Information del tuo negozio (che riporta la configurazione PHP effettiva) oppure un phpinfo() temporaneo, se lì non c'è una sezione Redis, un backend cache Redis non funzionerà a prescindere da ciò che dice la CLI, e ricorda che il backend stesso deve essere aggiunto da un modulo prima ancora di comparire.

Se il tuo hosting non offre affatto Redis e non intende farlo, quella è davvero una decisione di hosting, non di cache, ne parliamo in modo diretto in Scegliere l’hosting per PrestaShop: cosa conta davvero e cosa è solo marketing. La cache non può salvare un hosting che non ti dà gli strumenti.

Passaggio 1, Abilita la cache degli oggetti dal back office

Nel tuo negozio, apri Advanced Parameters → Performance e trova la sezione Caching, la posizione esatta nella pagina varia in base alla versione. Poi:

• Imposta Use cache su Yes.
• In Caching system, scegli il backend Redis. Ricorda che compare qui solo se un modulo o un backend cache personalizzato lo ha aggiunto (e se l'estensione PHP redis è caricata), PrestaShop standard elenca solo filesystem e opzioni in stile Memcached. Se non c'è una scelta Redis, installa/abilita il modulo che la fornisce e conferma che l'estensione redis sia caricata; vedi i prerequisiti.
• Compila i campi di connessione che compaiono:
  • Server (IP/hostname): 127.0.0.1 per Redis sulla stessa macchina, oppure l'hostname del container/servizio (ad es. redis) in una configurazione Docker o orchestrata.
  • Port: 6379, salvo modifiche intenzionali.
  • Database: 0 per un singolo negozio. Se più installazioni PrestaShop condividono un server Redis, assegna a ciascuna un numero di database diverso, così non leggono le chiavi l'una dell'altra, Redis offre di default i database da 0 a 15.
• Clicca su Add server, poi su Save.

L'elenco server nativo qui è una configurazione multi-server in stile Memcached; alcuni adattatori/moduli Redis permettono di aggiungere più server cache, ma la ridondanza Redis multi-server non è una funzionalità garantita di PrestaShop, verifica che il tuo modulo Redis la supporti davvero prima di contarci. Per un negozio su una sola macchina, una singola voce è comunque la norma. Dopo il salvataggio, la cache degli oggetti è attiva immediatamente, non c'è un passaggio separato di "riscaldamento"; la cache si riempie man mano che le pagine vengono visitate.

Passaggio 2, Verifica che stia davvero usando Redis (non darlo per scontato)

La schermata di configurazione di Redis contiene i campi di connessione: host, porta, password, indice del database e prefisso delle chiavi.

Un'impostazione salvata non è una prova. PrestaShop può accettare una configurazione Redis e continuare a servire pagine mentre la cache resta vuota, per esempio se la connessione fallisce silenziosamente sotto carico. Conferma che funzioni prima di fidarti:

• Naviga alcune pagine del front office (home, una categoria, un prodotto) per generare scritture in cache.
• Sul server esegui redis-cli e poi DBSIZE sul numero di database che hai scelto. Consideralo un rapido controllo di buon senso, non una prova: su un negozio funzionante il conteggio dovrebbe uscire da 0 e crescere mentre navighi, ma il numero esatto non è un segnale affidabile, prefissi della cache, database selezionato, TTL e comportamento di svuotamento, implementazione dell'adattatore e anche semplicemente un catalogo piccolo rendono fuorviante il valore grezzo di DBSIZE.
• Per una conferma reale usa redis-cli INFO (osserva keyspace_hits/keyspace_misses che aumentano) e redis-cli MONITOR per qualche secondo mentre ricarichi una pagina (poi Ctrl-C, non lasciare mai MONITOR in esecuzione su un negozio trafficato, è esso stesso un costo in termini di prestazioni). Dovresti vedere un flusso di comandi GET e SET con i prefissi chiave del tuo backend cache; controllare quei prefissi specifici dell'adattatore conferma che sia davvero il tuo negozio a parlare con questa istanza. Il silenzio significa che PrestaShop non sta parlando con questa istanza Redis.

Quindi? Questo controllo da trenta secondi è la differenza tra "ho abilitato Redis" e "Redis sta mettendo in cache il mio negozio". Molti negozi girano per mesi con una cache configurata ma morta perché nessuno ha verificato che il conteggio delle chiavi si fosse mai mosso da zero.

La versione shell di questa verifica è abbastanza breve da tenerla nelle note di distribuzione:

redis-cli -h 127.0.0.1 -p 6379 PING
redis-cli -h 127.0.0.1 -p 6379 DBSIZE
redis-cli -h 127.0.0.1 -p 6379 INFO stats | egrep 'keyspace_hits|keyspace_misses'

Passaggio 3, Sposta le sessioni su Redis (opzionale, a livello PHP)

Per le sessioni PHP, questa configurazione appartiene a PHP, non a un campo del back office di PrestaShop. Un tipico gestore di sessioni Redis ha questo aspetto:

session.save_handler = redis
session.save_path = "tcp://127.0.0.1:6379?database=1&prefix=pssess:"

L'archiviazione delle sessioni è una decisione separata e un file separato. Per impostazione predefinita PrestaShop scrive su disco un file di sessione per ogni visitatore; con una concorrenza reale, questo continuo lavoro sul filesystem diventa un collo di bottiglia proprio sugli hosting dove hai più bisogno di aiuto. Lo spostamento delle sessioni su Redis si configura in PHP, nel tuo php.ini o, meglio, nel pool PHP-FPM di questo sito:

session.save_handler = redis

session.save_path = "tcp://127.0.0.1:6379?database=1"

Nota il numero di database volutamente diverso (1) rispetto alla cache degli oggetti (0). Tenerli separati significa poter svuotare la cache degli oggetti, cosa che farai regolarmente dopo modifiche a template o moduli, senza disconnettere ogni cliente che sta completando un ordine. Mescolarli in un unico database trasforma una pulizia cache innocua in un'ondata di carrelli abbandonati. Riavvia PHP-FPM dopo la modifica, poi conferma con redis-cli -n 1 DBSIZE che il valore cresca quando arrivano visitatori.

Una nota sulla durabilità specifica per le sessioni: Redis è in memoria, quindi un riavvio di Redis può eliminare le sessioni salvate dall'ultimo snapshot su disco, disconnettendo i clienti attivi. Se memorizzi le sessioni in Redis su un negozio di produzione, abilita la persistenza AOF (append-only-file), così un riavvio perde secondi di dati di sessione invece di minuti, gli snapshot RDB da soli vanno bene per una cache degli oggetti eliminabile, ma sono troppo grossolani per carrelli attivi.

Passaggio 4, Imposta un limite di memoria e una policy di espulsione

Una cache degli oggetti lasciata crescere senza limiti finirà per consumare la RAM necessaria ai worker PHP e al database, e il rimedio (un server lento che fa swapping) è peggiore del problema. Dai a Redis un budget nella sua configurazione (redis.conf):

• maxmemory, un limite rigido. Il valore corretto dipende da dimensione del catalogo e traffico; molte configurazioni con un solo negozio stanno comodamente in poche centinaia di MB per la cache degli oggetti, di più se conservi anche le sessioni. Osserva l'uso reale (sezione successiva) invece di stimare troppo in alto.
• maxmemory-policy allkeys-lru, quando il limite viene raggiunto, espelle le chiavi usate meno di recente. Per una cache pura è l'impostazione sicura di default: le voci obsolete o toccate raramente vengono eliminate per prime e PrestaShop le ricostruisce semplicemente alla richiesta successiva. (Se la stessa istanza Redis conserva anche sessioni, preferisci una policy volatile-lru con TTL, così l'espulsione non può eliminare silenziosamente una sessione autenticata, oppure, soluzione più pulita, tieni le sessioni su un'istanza Redis separata.)

Passaggio 5, Misura il guadagno con onestà

Il motivo per fare tutto questo è la velocità, quindi misura la velocità, ma misurala correttamente, perché Redis migliora il tempo di risposta del server, non le parti della pagina che dipendono da immagini e asset front-end. La metrica che cambia è il Time To First Byte (TTFB): quanto tempo impiega il server a iniziare a inviare la pagina. La cache degli oggetti riduce le letture ripetute dal disco che gonfiano il TTFB, quindi è lì che vedrai l'effetto.

• Prima di cambiare qualsiasi cosa, registra una base di partenza. Apri più volte una pagina prodotto e una pagina categoria rappresentative (così misuri una cache calda, non fredda) e annota il tempo di risposta del server, la scheda Network dei DevTools del browser mostra il TTFB per ogni richiesta, e anche strumenti come PageSpeed Insights o WebPageTest lo riportano. Per un numero lato server confrontabile, la misura più pulita è una richiesta da utente non autenticato con cache del browser disabilitata.
• Abilita Redis, verificalo (Passaggio 2), riscalda la cache navigando, poi rimisura le stesse pagine nello stesso modo.
• Confronta il TTFB, non il titolo generale "caricamento pagina". Un'immagine hero non ottimizzata da 5 MB dominerà il tempo di caricamento completo e nasconderà un reale miglioramento backend, portandoti a concludere erroneamente che Redis "non ha fatto nulla".

Quanto più veloce? Onestamente, dipende interamente dal punto di partenza. Un negozio su hosting condiviso lento con I/O disco pesante può vedere una forte riduzione del TTFB, perché quello è esattamente il collo di bottiglia che Redis rimuove; un negozio già su un VPS NVMe veloce con carico leggero può vedere un guadagno più modesto, perché le letture da disco non lo penalizzavano molto fin dall'inizio. Chiunque ti citi una percentuale universale sta tirando a indovinare. L'unico numero che conta è quello che misuri sul tuo negozio, prima e dopo, sulle stesse pagine. Per un metodo strutturato per diagnosticare prima dove va davvero il tempo, vedi Il tuo negozio è lento? Come verificarlo e cosa fare.

Monitorare Redis quando è attivo

Dopo la configurazione, una manciata di valori da redis-cli INFO ti dice se la cache è sana o sta fallendo in silenzio:

Risoluzione dei problemi di configurazione che incontrerai davvero

Il backend Redis non è nel menu a tendina

Due cause: il modulo/backend personalizzato che aggiunge Redis come sistema di cache non è installato (PrestaShop standard non lo elenca), oppure l'estensione PHP redis non è caricata nel runtime PHP del tuo negozio. Conferma che il modulo che lo fornisce sia attivo, ricontrolla l'estensione dalla pagina Information del negozio o con phpinfo() (non dalla CLI), e verifica di aver riavviato PHP-FPM dopo aver installato l'estensione.

Cache configurata, ma DBSIZE resta a 0

PrestaShop potrebbe non riuscire a raggiungere Redis, ma un database vuoto da solo non dimostra un errore di connessione. I sospetti abituali: Redis è in ascolto solo su 127.0.0.1 mentre PrestaShop si connette da un altro host/container (comune in Docker, nel campo Server indica il nome del servizio, non localhost); un firewall blocca la porta 6379; oppure Redis semplicemente non è in esecuzione.

Dati obsoleti dopo la modifica di un prodotto o di una categoria

Se le modifiche non compaiono finché non svuoti la cache, la cache degli oggetti non viene invalidata come previsto. Svuotare la cache di PrestaShop da Advanced Parameters → Performance (il pulsante Clear cache) è la soluzione pulita; redis-cli -n 0 FLUSHDB cancella solo il database della cache degli oggetti senza toccare le sessioni nel database 1. Se il problema si ripete, il colpevole probabile è un modulo che non svuota la propria cache al salvataggio.

Clienti disconnessi dopo un deploy o un riavvio

Sessioni in Redis senza persistenza AOF, oppure sessioni che condividono un database con la cache degli oggetti e vengono svuotate insieme. Separa i database (Passaggio 3) e abilita AOF.

Redis è uno strato, metti l'ordine giusto

Redis rende di più quando gli strati sottostanti sono già solidi, e non può compensare un problema che non affronta. Prima di Redis o insieme a Redis:

• OPcache memorizza in cache il bytecode PHP compilato, così il motore smette di rianalizzare i file a ogni richiesta. È quasi gratuito e complementare, OPcache accelera il codice, Redis accelera i dati. Usali entrambi.
• Un database gonfio o senza indici adeguati produce comunque query lente alla prima richiesta, che Redis maschera solo finché la cache non scade. Le correzioni alla base, ottimizzazione delle query e pulizia, sono trattate in performance tuning your PrestaShop store e Pulizia del database: perché il tuo negozio rallenta nel tempo.
• Le vere cause alla radice di un negozio lento, troppi moduli, hook pesanti, hosting debole, sono diagnosticate in Cosa rallenta davvero PrestaShop. Mettere in cache il risultato di una query sbagliata lascia comunque lenta la prima richiesta non in cache; correggi la query e la cache rende immediata una cosa già veloce.

Per un esempio pratico di tutti questi strati sovrapposti su un negozio reale e molto esteso, guarda come appare nella scheda dei punteggi in PageSpeed 99/100 on a real PrestaShop store with 130 modules.

Domande di configurazione che arrivano dopo il menu a tendina

Devo mantenere i file CacheFs dopo il passaggio a Redis? No. Una volta che il backend della cache degli oggetti è Redis e lo hai verificato (Passaggio 2), la vecchia cache filesystem sotto var/cache/ è solo dato obsoleto. Svuotarla da Advanced Parameters → Performance è innocuo e ordinato. Però non eliminare var/cache/ a mano su un negozio PrestaShop 9: il container Symfony dell'amministrazione vive lì e una cancellazione brutale può mandare il back office in errore 500. Usa il pulsante Clear cache del back office.

La cache degli oggetti e le sessioni dovrebbero condividere una sola istanza Redis? Possono farlo, ma tienile in database diversi, cache degli oggetti in 0, sessioni in 1 (Passaggio 3). È questa separazione che ti permette di svuotare la cache degli oggetti dopo una modifica a un template o a un modulo senza disconnettere ogni cliente mentre completa l'ordine. Se puoi eseguire una seconda istanza, mettere le sessioni su un Redis dedicato con persistenza AOF è ancora più pulito, perché le sessioni richiedono una durabilità che una cache eliminabile non richiede.

È sicuro eseguire FLUSHALL per svuotare la cache? No, FLUSHALL cancella ogni database dell'istanza, incluse sessioni e qualsiasi altro negozio che la condivida, facendo perdere carrelli attivi. Svuota la cache degli oggetti dal back office, oppure usa redis-cli -n 0 FLUSHDB per cancellare solo il database della cache degli oggetti lasciando intatte le sessioni nel database 1. Non usare mai FLUSHALL su un'istanza di produzione.

Perché il mio tasso di hit è calato dopo la messa online? Di solito per una di tre ragioni: maxmemory impostato troppo basso, quindi Redis espelle chiavi (controlla evicted_keys, dovrebbe essere vicino a zero per una cache pura), una pianificazione di svuotamento troppo aggressiva che rigenera continuamente la cache, oppure un modulo problematico che svuota la cache a ogni salvataggio. Aumenta prima maxmemory, poi controlla cosa sta svuotando la cache. Una cache calda e sana sta comodamente sopra il 90% di hit.

Redis sostituisce OPcache? No, mettono in cache cose diverse e li usi entrambi. OPcache memorizza il bytecode PHP compilato, così il motore smette di rianalizzare i file a ogni richiesta; Redis memorizza i dati che PrestaShop ricostruisce. Su PHP 8 il JIT fa parte di OPcache ed è il guadagno gratuito lato server più importante. Attiva OPcache indipendentemente dal fatto che tu adotti Redis.

Se preferisci non toccare il server

Tutto quanto sopra si può fare da back office e shell, ma presuppone che tu sappia modificare un pool PHP-FPM, impostare una policy maxmemory e leggere redis-cli INFO, terreno comodo per un'agenzia, meno per un titolare di negozio che vuole solo la velocità senza fare l'amministratore di sistema. È il vuoto che il nostro modulo mprinstantredis è stato progettato per colmare: collega la cache degli oggetti di PrestaShop a Redis, mantiene separati i database di sessioni e cache così uno svuotamento cache non fa mai perdere carrelli attivi, e mostra tasso di hit e valori di memoria dentro il back office invece che in un terminale. Che cosa ti porta, in pratica? La stessa configurazione correttamente separata e monitorata descritta qui, configurata dall'amministrazione invece che dai file di configurazione del server, utile quando vuoi il risultato senza occuparti dell'impianto server. Il percorso manuale di questa guida resta del tutto valido; il modulo elimina semplicemente i passaggi che spingono la maggior parte dei commercianti a cercare uno sviluppatore.

Lo schema da ricordare: Redis su PrestaShop comprende tre lavori separati, cache degli oggetti (back office), sessioni (PHP) e backend opzionale per la cache della pagina intera (un modulo). Abilita consapevolmente quelli che vuoi, verifica che ciascuno sia davvero attivo invece di presumerlo, tieni sessioni e cache in database diversi e giudica il risultato dal TTFB misurato sul tuo negozio. Fallo e Redis smette di essere una casella che speri abbia aiutato e diventa uno strato di cui puoi dimostrare il funzionamento.