In queste settimane sto ricevendo la stessa telefonata da merchant molto diversi tra loro. Il tono è quasi sempre lo stesso: “gli ordini sono raddoppiati, il sito rallenta, cosa facciamo?”. Con i negozi fisici chiusi e mezza Italia chiusa in casa, categorie che davano numeri prevedibili da anni si sono ritrovate un picco di traffico e di ordini che nessuno aveva messo a budget. Alimentari, prodotti per la casa, articoli sportivi da usare in balcone: domanda arrivata tutta insieme, senza preavviso.
Voglio raccontarvi come ragiono quando un’infrastruttura Magento va sotto pressione all’improvviso. Non è teoria: è quello che sto facendo in questi giorni, con priorità che cambiano di ora in ora. La mia tesi di fondo è semplice e la anticipo subito: sotto un picco improvviso non si “ottimizza” tutto, si sceglie cosa proteggere e cosa sacrificare. Chi prova a salvare ogni funzione contemporaneamente le perde tutte.
Cosa si rompe per primo
La cosa controintuitiva è che, quasi mai, a cedere è il frontend. Le pagine prodotto e categoria di solito reggono, perché sono servite dalla cache. A saturarsi per prima è quasi sempre la parte “calda” e non cacheabile: il database sotto il peso di carrello, checkout e login concorrenti, e i processi asincroni che si accodano. Un merchant fashion di taglia media, la settimana scorsa, aveva l’homepage velocissima e il checkout che andava in timeout. Il visitatore vedeva un sito reattivo e poi non riusciva a pagare. Il caso peggiore, perché il traffico c’è ma non converte.
La cache è la prima linea, ma va difesa
La Full Page Cache con Varnish davanti è ciò che tiene in piedi tutto. Il punto è il hit ratio: se Varnish serve il 95% delle richieste, il carico che arriva a PHP e a MySQL è una frazione. Se scende, il backend prende in pieno un traffico per cui non è dimensionato.
Le due cose che controllo subito quando un sito soffre:
- Cosa sta bucando la cache. Un parametro di tracking mal gestito, un blocco reso “private” senza motivo, una promo che forza il bypass: bastano dettagli così a trasformare pagine cacheabili in richieste dinamiche. Con un picco, ogni miss si moltiplica.
- La durata del TTL. In condizioni normali tengo TTL prudenti per non mostrare stock vecchi. Sotto picco alzo la vita della cache dove posso permettermelo, accettando che una pagina categoria mostri una disponibilità aggiornata con qualche minuto di ritardo. È il primo baratto consapevole: un po’ di freschezza in cambio di stabilità.
Gli indexer: il nemico silenzioso
Qui sbagliano in tanti. Con un catalogo che si muove molto – prezzi che cambiano, stock che si svuota, prodotti che vanno esauriti – gli indexer in modalità “Update on Save” diventano un problema serio. Ogni salvataggio scatena una reindicizzazione che pesa sul database proprio quando il database è già la risorsa più contesa.
La prima mossa, se non è già così, è portare gli indexer su “Update by Schedule”. La reindicizzazione passa dal cron e non blocca più le operazioni. Ma non basta impostarlo: sotto picco il cron va tenuto d’occhio, perché se le code di indicizzazione si allungano il rischio è mostrare prezzi o disponibilità non allineati. Un e-commerce di alimentari con cui lavoro, in questi giorni, aveva l’indexer del price che accumulava ritardo perché il fornitore aggiornava i listini in continuazione. La soluzione non è stata tecnica ma organizzativa: concentrare gli aggiornamenti massivi in due finestre al giorno, fuori dai picchi di traffico.
Le code e il lavoro asincrono
Tutto ciò che può diventare asincrono, sotto picco, deve diventarlo. La message queue – RabbitMQ nelle installazioni più strutturate – serve esattamente a questo: togliere peso dalla richiesta sincrona dell’utente e spostarlo su consumer che lavorano in background. Invio email, aggiornamenti verso l’ERP, generazione di documenti: nessuna di queste cose deve rallentare il checkout.
Il ragionamento che faccio è: l’utente deve poter concludere l’ordine anche se il gestionale è lento o momentaneamente irraggiungibile. L’ordine entra in Magento, va in coda, e la sincronizzazione avviene quando il sistema a valle è pronto. Se il tuo checkout dipende in modo sincrono da una chiamata all’ERP, con un picco quella dipendenza diventa il tuo collo di bottiglia. È una delle prime cose che vado a verificare.
Hosting e scaling: la leva più rapida ma non magica
Aggiungere risorse è la leva più immediata, e va usata. Su un’infrastruttura cloud come Magento Commerce Cloud si può salire di taglia sui nodi applicativi e reggere più PHP-FPM concorrenti in tempi ragionevoli. Su un hosting tradizionale è più lento, ma qualcosa si fa: più worker, tuning di OPcache, più RAM dove serve.
Attenzione però: lo scaling orizzontale sui web node aiuta se il collo di bottiglia è la CPU applicativa. Se invece il problema è il database – ed è spesso lì – aggiungere web server serve a poco, anzi rischi di caricare ancora di più un MySQL già in affanno. Prima di scalare bisogna capire cosa sta saturando. Buttare hardware su un problema mal diagnosticato è il modo più veloce di spendere soldi senza risultato.
Cosa taglio e cosa proteggo
Arriviamo al punto per me più importante, quello che distingue chi gestisce un picco da chi lo subisce. Quando le risorse sono al limite, decido esplicitamente delle priorità.
Cosa proteggo, sempre: il percorso che porta soldi. Ricerca, pagina prodotto, aggiungi al carrello, checkout, pagamento. Questo flusso deve restare in piedi anche a costo di sacrificare tutto il resto.
Cosa sono pronto a tagliare o degradare temporaneamente: funzioni “belle da avere” che pesano sul backend e non spostano la conversione. Related products calcolati a runtime, moduli di raccomandazione, layered navigation con troppi filtri dinamici, widget che interrogano il database a ogni caricamento. In un caso ho disattivato per due giorni un modulo di recensioni che faceva query pesanti in pagina prodotto: nessuno se n’è accorto, il checkout ha ripreso a respirare.
Degrado anche l’esperienza dove serve: se devo scegliere tra un sito completo che va in timeout e un sito più spartano che accetta ordini, scelgo il secondo senza esitare. In emergenza la funzione batte l’estetica.
La lezione che mi porto da questi giorni
Un picco improvviso non è un problema di potenza, è un problema di priorità. La tecnologia c’è già – Varnish, indexer schedulati, message queue, scaling – ma serve la lucidità di decidere in fretta cosa conta. La cosa che dico a tutti i merchant in questi giorni è di non aspettare il picco per fare queste scelte: chi aveva l’infrastruttura ordinata sta reggendo, chi la stava tenendo insieme con lo scotch la sta pagando ora, tutta insieme.
Domande rapide
Qual è il primo controllo da fare quando Magento rallenta sotto picco?
L’hit ratio della Full Page Cache. Se Varnish non sta servendo la grande maggioranza delle richieste, il backend riceve un carico per cui non è dimensionato. Prima si capisce cosa buca la cache, poi si guarda il resto.
Meglio scalare l’hosting o ottimizzare la configurazione?
Dipende da cosa satura. Se è la CPU applicativa, scalare i web node aiuta. Se è il database, aggiungere web server serve a poco: prima si diagnostica, poi si scala.
Gli indexer vanno tenuti su Update on Save o Update by Schedule?
Sotto picco, sempre “Update by Schedule”. La reindicizzazione passa dal cron e non blocca le operazioni, ma il cron va monitorato per non mostrare prezzi o stock non allineati.
Cosa si può disattivare in emergenza senza fare danni?
Le funzioni che pesano sul backend ma non toccano la conversione: raccomandazioni a runtime, widget con query pesanti, moduli accessori. Si protegge il flusso ricerca-prodotto-carrello-checkout-pagamento, si degrada il resto.
Chi sono. Mi occupo di Magento e Adobe Commerce da anni, come progettista e gestore di infrastrutture e-commerce per merchant di fascia media. Sono tra i primi in Italia ad aver ottenuto la certificazione Adobe Commerce. Su questo blog racconto quello che vedo dal campo, senza filtri e senza vendere nulla.