Redis per PrestaShop: l'accelerazione di cui il tuo negozio probabilmente ha bisogno

La maggior parte dei consigli sulle prestazioni di PrestaShop finisce prima o poi sulla stessa parola: Redis. Viene raccomandato come un tonico. "Aggiungi Redis, il tuo negozio sarà più veloce", spesso senza che nessuno spieghi che cosa sostituisce davvero, quali negozi ne hanno realmente bisogno o per quali pagine lente non farà nulla. Questo articolo è la versione onesta di quella conversazione. Parla di quando Redis è la prossima mossa giusta per il tuo negozio specifico, di cosa cambia sotto il cofano in un'installazione PrestaShop e di come decidere, prima di pagare per un potenziamento VPS di cui potresti non avere bisogno. Per l'installazione passo passo e le impostazioni che generano i miglioramenti, rimandiamo alla nostra guida collegata su configurazione della cache Redis e miglioramenti delle prestazioni; qui il punto è la decisione, non i comandi da eseguire.

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.

Che cos'è davvero Redis, in un paragrafo onesto

Redis è un archivio chiave-valore in memoria, un dizionario molto veloce che vive nella RAM invece che su disco. Gli passi una chiave (per esempio, i dati renderizzati per la categoria 12) e lui restituisce il valore in una frazione di millisecondo, perché non tocca il disco e non interroga MySQL. Il trucco è tutto qui: non è un "plugin di velocità", è un posto più rapido in cui conservare cose che PrestaShop sta già mettendo in cache. Non è specifico di PrestaShop e non è una novità. È un'infrastruttura open-source matura che gira come servizio sul tuo server (o come componente aggiuntivo gestito dal tuo hosting). Per il proprietario di un negozio, il punto è questo: ogni dato servito da Redis è una query al database che non parte e una lettura da disco che non avviene; su una pagina trafficata, questi risparmi si sommano fino a rendere il negozio visibilmente più veloce.

Che cosa sostituisce Redis dentro PrestaShop, nello specifico

PrestaShop mette già in cache diverse cose; di default le parcheggia su disco o dentro il database MySQL. Redis può subentrare come livello di archiviazione per cache selezionate e per la gestione delle sessioni, ma solo dove un adattatore di cache supportato, un modulo o un gestore di sessione PHP è configurato per puntare a Redis; non è un archivio nativo e automatico per ogni cache integrata. In un negozio PrestaShop, i pezzi rilevanti sono:

• Cache degli oggetti (la parte importante). Il livello di cache di PrestaShop (Parametri avanzati → Prestazioni → Cache, l'impostazione Cache i cui backend disponibili variano in base alla versione di PrestaShop e alle estensioni PHP installate, storicamente filesystem (CacheFs), Memcached, APC/APCu e Xcache; Redis non è un'opzione standard del core e richiede un modulo o un adattatore personalizzato) conserva oggetti che PrestaShop ricostruisce su quasi ogni pagina, valori di configurazione, albero delle categorie, liste degli hook, dati di valuta e lingua. Servita da disco (CacheFs), è una raffica di piccole letture di file; servita da Redis, è una consultazione in memoria. È qui che arriva gran parte del guadagno reale.
• Cache dei template Smarty. PrestaShop compila i template .tpl e mette in cache il risultato. Di default questi file compilati e memorizzati in cache vivono su disco sotto var/cache/ (le versioni più vecchie usavano cache/smarty), PrestaShop standard non sposta la cache di compilazione Smarty in Redis, quindi questo avviene solo tramite un'integrazione personalizzata o di terze parti, non tramite un'impostazione integrata.
• Sessioni PHP. I dati di sessione del cliente, stato di accesso, contenuto del carrello, usano di default file su disco (il gestore nativo di sessione su file di PHP). Spostare le sessioni su Redis alleggerisce il filesystem da quel carico di lettura/scrittura e, nelle configurazioni multi-server, consente a ogni server applicativo di condividere un unico archivio sessioni invece di tenere file locali separati.
• Cache a pagina intera. Le pagine intere già renderizzate per i visitatori anonimi possono essere conservate in Redis e restituite quasi all'istante. È un tema a sé, con compromessi reali, cosa mettere in cache, come invalidarla, cosa si rompe per i clienti autenticati, quindi lo trattiamo nell'approfondimento sui moduli di cache a pagina intera invece di liquidarlo qui in fretta.

La formulazione onesta è questa: Redis non fa fare meno lavoro a PrestaShop. Fa sì che il lavoro che PrestaShop ripete già, le stesse letture di configurazione, lo stesso albero categorie, gli stessi template compilati, richiesta dopo richiesta, torni dalla RAM invece che da disco o da MySQL.

Il tuo negozio ha davvero bisogno di Redis? Uno schema decisionale

Questa è la domanda che chi vende il tonico salta. Redis vale la pena per alcuni negozi ed è puro sovraccarico per altri. Passa il tuo negozio attraverso questo schema prima di spendere qualcosa:

Se non sai ancora quale di questi casi ti rappresenta, quello è il passo preliminare, non Redis. Prima fai diagnosi: come verificare se il tuo negozio è lento e cosa lo causa, e l'analisi di cosa rende davvero lento PrestaShop, database, moduli e hosting. Comprare RAM per Redis per risolvere un problema che poi si rivela essere un'immagine hero da 4 MB è un errore comune, ed evitabile.

Che cosa Redis non risolverà (così non dai la colpa alla cosa sbagliata)

Questo conta tanto quanto i vantaggi, perché un proprietario di negozio che installa Redis aspettandosi che sistemi tutto finisce deluso e convinto che la cache sia fumo negli occhi. Redis non fa nulla per:

• Query non cacheabili. Un controllo delle giacenze in tempo reale o un calcolo prezzo per singolo cliente gira su ogni pagina per progettazione, non c'è nulla da mettere in cache. Se una query specifica è lenta, va corretta la query, ed è un lavoro di database: vedi ottimizzazione delle prestazioni dalle query database alla cache a pagina intera.
• Moduli pesanti. Un modulo che esegue PHP costoso a ogni richiesta continua a eseguirlo. La cache accelera le letture dei dati, non i percorsi di codice.
• Risorse front-end non ottimizzate. Redis è una cache lato server; non tocca mai un'immagine prodotto da 5 MB o uno script che blocca il rendering. Quello è compito di CCC, compressione immagini e CDN.
• Un database gonfio. Anni di carrelli morti, sessioni ospite obsolete e righe orfane rallentano MySQL in modi che la cache può solo mascherare. Ripulisci anche il marcio: perché il tuo negozio rallenta nel tempo e la pulizia che lo rimette in carreggiata.
• API esterne lente. Una chiamata di pagamento o spedizione a una terza parte durante il caricamento pagina è latenza che non controlli; Redis non può mettere in cache il server di qualcun altro.

Redis è un moltiplicatore per un negozio già ordinato, non un salvataggio per uno disordinato. L'ordine corretto è: riduci i moduli, correggi le query evidenti, pulisci il database, poi aggiungi Redis, così le operazioni che restano tornano dalla RAM.

Redis vs Memcached su PrestaShop

Il menu a tendina della cache di PrestaShop elenca anche Memcached, quindi vale la pena chiudere il confronto. Entrambi tengono i dati in RAM; per un negozio PrestaShop le differenze pratiche sono queste:

Per la grande maggioranza dei negozi PrestaShop, Redis è la scelta giusta. Già persistenza e svuotamento limitato al prefisso bastano a giustificarlo, e lo scenario multi-shop qui sotto chiude il cerchio.

Redis per multi-shop e multi-server

Se gestisci più negozi da un'unica installazione PrestaShop, o lo stesso negozio su più server applicativi, una sola istanza Redis può servirli tutti. Ogni negozio riceve il proprio spazio di chiavi tramite un prefisso chiave, quindi carrelli e oggetti in cache non passano mai da un negozio all'altro pur condividendo la RAM sottostante, più economico e più semplice che eseguire una cache separata per ogni negozio. Questa disciplina dei prefissi è anche ciò che rende possibile uno svuotamento con ambito: svuotare la cache del negozio B dopo un import prezzi senza far ripartire a freddo il negozio A. In una configurazione bilanciata, la stessa istanza dà a ogni server una cache e un archivio sessioni unici, così un cliente non viene disconnesso solo perché il bilanciatore lo ha spostato su un nodo diverso.

Il limite dell'hosting condiviso

Il vicolo cieco più comune è questo: Redis richiede un servizio in esecuzione sul server, e l'hosting condiviso non lo offre quasi mai (niente SSH, nessun modo di avviare un daemon). Se sei su hosting condiviso e vuoi Redis, la vera decisione non è "quale modulo". È se il tuo negozio ha superato i limiti dell'hosting condiviso. Di solito un negozio abbastanza grande da beneficiare di Redis è già abbastanza grande da giustificare un VPS, e la scelta dell'hosting merita un'analisi a parte: cosa conta davvero nell'hosting PrestaShop e cosa è solo marketing. Non pagare per un piano "pronto per Redis" prima di aver confermato che Redis è davvero il tuo collo di bottiglia.

Come sapere se sta funzionando davvero

La dashboard delle prestazioni mostra schede per TTFB, LCP, tasso di hit della cache e query lente, un grafico dell'andamento dei Web Vitals e il backend della cache impostato su file.

Una cache che non puoi vedere è una cache di cui non puoi fidarti. Due numeri ti dicono se Redis si sta guadagnando il suo posto, e sia i log di PrestaShop sia l'output Redis INFO li espongono:

Da shell, il controllo minimo utile è questo:

redis-cli -h 127.0.0.1 -p 6379 INFO stats | egrep 'keyspace_hits|keyspace_misses'
redis-cli -h 127.0.0.1 -p 6379 INFO memory | egrep 'used_memory_human|maxmemory_human|used_memory_peak_human'

• Tasso di successo. Il rapporto tra riscontri in cache e ricerche totali (keyspace_hits vs keyspace_misses in Redis INFO). Lo vuoi comodamente sopra il 90%. Un tasso di successo basso significa che la cache continua a essere rigenerata, di solito per una pianificazione di svuotamento troppo aggressiva o per troppa poca memoria, e stai pagando Redis senza ottenere il beneficio.
• Margine di memoria. Tieni d'occhio used_memory rispetto al limite maxmemory. Quando Redis raggiunge il tetto, inizia a espellere chiavi, il tasso di successo cala e il tuo negozio "veloce" rallenta in silenzio. Come stima iniziale: fino a ~5k prodotti spesso stanno bene in 256MB; 5k–50k tendono a richiedere 512MB–1GB; cataloghi molto grandi, di più, ma trattali come punti di partenza da verificare rispetto al tuo vero used_memory_peak, non come garanzie.

E misura il risultato che paga le bollette, non solo gli interni della cache. Prima di cambiare qualcosa, annota il tuo Time to First Byte e il tempo medio di generazione pagina (dal profiler di PrestaShop, abilitato tramite _PS_DEBUG_PROFILING_ in config/defines.inc.php su staging, oppure dalla barra di debug Symfony, o dai tuoi strumenti APM e log server); dopo che Redis è attivo e caldo, confronta gli stessi numeri su traffico reale per diversi giorni, non in un pomeriggio tranquillo. Una riduzione del tempo di generazione pagina su categorie e pagine prodotto pesanti è il segnale che ha funzionato.

Collegare PrestaShop a Redis senza YAML

Puoi collegare Redis a PrestaShop a mano, modificare configurazioni, impostare la classe di cache, gestire i dettagli di connessione, riavviare servizi e sperare di non aver digitato male un host. È fattibile, e la nostra guida alla configurazione percorre la strada manuale. Il motivo per cui abbiamo creato Redis Cache Manager & Monitor è che la via manuale non ti dà alcun ciclo di feedback: non puoi vedere il tuo tasso di successo, non sai se la memoria sta per iniziare a espellere chiavi, e svuotare la cache in sicurezza significa sapere esattamente quali chiavi appartengono a quale negozio.

Redis Cache Manager & Monitor gestisce tutto questo rapporto dal pannello di amministrazione. Che cosa significa in pratica? Inserisci host e porta Redis e testi la connessione prima di salvare, il modulo restituisce versione server, memoria usata, client connessi e uptime, così sai che è raggiungibile invece di tirare a indovinare. Attivi o disattivi cache degli oggetti, archiviazione delle sessioni e cache a pagina intera in modo indipendente, usando solo ciò che serve al tuo negozio. Il pannello mostra tasso di successo e uso memoria in tempo reale. I due numeri sopra, quindi "sta funzionando?" diventa un colpo d'occhio, non una sessione redis-cli. E quando salvi la configurazione può svuotare solo le chiavi del tuo negozio (per prefisso) invece dell'intera istanza, ed è questo che lo rende sicuro su un server multi-shop. Il vantaggio non è "abbiamo reso Redis elegante". È che un proprietario di negozio, non solo un amministratore di sistema, può eseguire Redis correttamente e dimostrare che sta aiutando. Che cosa succede se Redis diventa indisponibile dipende interamente da come è collegato ogni livello: un adattatore cache o un gestore di sessione configurato male può rompere le richieste invece di degradare in modo pulito, quindi il fallback controllato è qualcosa da verificare, non da dare per scontato. Redis Cache Manager & Monitor è progettato per tornare alla cache predefinita di PrestaShop se Redis cade, ma testa questo comportamento sulla tua configurazione prima di farci affidamento.

Le domande che i proprietari di negozi fanno prima di passare a Redis

Redis metterà in cache anche il carrello e le pagine di pagamento? Non come cache degli oggetti, e non lo vorresti. La cache degli oggetti accelera le letture ripetute dietro una pagina, configurazione, albero categorie, liste degli hook, non il carrello, il pagamento o lo stato di accesso per singolo cliente, che sono dinamici per natura e devono restare live. Redis può memorizzare le sessioni (così un carrello sopravvive tra server diversi), ma è un lavoro diverso dal mettere in cache una pagina renderizzata. La cache a pagina intera è il livello che restituisce HTML intero, ed è correttamente limitata ai visitatori anonimi, un cliente autenticato o chiunque abbia un carrello la bypassa. Metti in cache la vetrina, mai il carrello o l'accesso.

Meglio OPcache o Redis come prima mossa? Prima OPcache. È quasi gratuito, arriva con PHP e mette in cache il bytecode compilato, così il motore smette di rileggere e riparsare i file a ogni richiesta. Su PHP 8 il JIT fa parte di OPcache ed è il più grande vantaggio lato server gratuito che il PHP più recente offre a un negozio limitato dalla CPU. Redis mette in cache i dati; OPcache mette in cache il codice. Sono complementari, ma OPcache è quello da attivare prima di spendere qualcosa in RAM per Redis.

Che cosa succede al mio negozio se il server Redis va giù? Dipende interamente da come è collegato ogni livello, e vale la pena verificarlo invece di darlo per scontato. Una cache degli oggetti collegata in modo pulito dovrebbe tornare alla cache predefinita di PrestaShop se Redis cade; un adattatore cache o un gestore di sessione configurato male può invece rompere le richieste. Testa il caso di errore sulla tua configurazione, ferma Redis su staging e carica una pagina, prima di fare affidamento su un fallback pulito in produzione.

Redis o Memcached, cambia davvero qualcosa per un singolo negozio? Per la maggior parte dei negozi PrestaShop, Redis. I punti decisivi sono concreti e piccoli: Redis sopravvive a un riavvio con persistenza opzionale su disco (Memcached riparte a freddo con ogni cache dopo un riavvio), e Redis svuota per prefisso chiave, così puoi pulire un negozio senza azzerare gli altri. Memcached è accettabile per installazioni legacy e memorizza sessioni PHP se lo colleghi a livello PHP, ma su una nuova configurazione raramente c'è un motivo per sceglierlo al posto di Redis. Varnish è un altro strumento ancora, una cache HTTP a pagina intera che sta davanti a PHP, non un backend di cache degli oggetti intercambiabile, quindi confrontalo con la tua decisione sulla cache a pagina intera, non con Redis come cache degli oggetti.

Quanta RAM dovrei dare a Redis? Parti dal tuo catalogo e verifica sui dati reali, non tirare alto a caso. Come stime iniziali: fino a ~5k prodotti spesso stanno in 256MB; 5k–50k tendono a richiedere 512MB–1GB; cataloghi più grandi, di più. Poi controlla used_memory_peak rispetto al tuo maxmemory, se Redis raggiunge il tetto, espelle chiavi, il tasso di successo cala e il tuo negozio "veloce" rallenta in silenzio. Il numero giusto è quello confermato dal tuo output INFO memory.

In sintesi

Redis è uno degli interventi con il miglior rapporto tra sforzo e impatto disponibili per un negozio PrestaShop, quando è davvero l'intervento giusto. La disciplina sta proprio in quella condizione. Se il tuo negozio è su un VPS, ha abbastanza traffico ricorrente e profondità di catalogo da riempire una cache, e hai già gestito immagini, moduli pesanti e database gonfio, Redis trasforma il lavoro che PrestaShop ripete tutto il giorno in ricerche in memoria, e lo vedrai nel TTFB. Se sei su hosting condiviso, o il tuo vero problema è una query non cacheata o un'immagine sovradimensionata, Redis è lo strumento sbagliato e i tuoi soldi vanno spesi altrove prima. Diagnostica, metti ordine, poi metti in cache, e misura il tasso di successo, così non dovrai mai indovinare se Redis si è guadagnato la sua RAM. Quando sei pronto a collegarlo, la guida alla configurazione e alle prestazioni riparte da qui.