Il tuo negozio online sopravvive alle settimane tranquille di ottobre su un piano di hosting costruito per il traffico ordinario. Il Black Friday non chiede il permesso prima di moltiplicare quel traffico per dieci o venti volte in una sola ora. Il load testing prima di novembre mostra dove il tuo stack cede: la pagina di checkout, il database, il server delle immagini o il piano di hosting stesso. Saltalo e lo scoprirai dal vivo, davanti ai clienti paganti, nel giorno in cui una pagina lenta costa di più. Questo articolo copre quali strumenti funzionano davvero, quanto costano, in quale ordine testare e dove i siti WordPress tendono a rompersi per primi.
Cosa fa realmente il traffico del Black Friday a un sito
Un martedì normale invia un rivolo di visitatori che navigano, aggiungono un articolo e se ne vanno. Il Black Friday invia una folla che atterra sulle stesse cinque pagine prodotto pochi minuti dopo l'invio della tua email di sconto. Il server tratta ogni visita come una richiesta fresca: una query del database, un calcolo del carrello, una scrittura di sessione. Ogni livello dello stack, il server web, PHP, il database, il gateway di pagamento, ha un limite.
Quando la folla supera quel limite, le pagine rallentano e il checkout va in timeout. Alcuni di quei visitatori se ne vanno senza comprare nulla e raramente tornano per riprovare in seguito. Il load testing trova il limite in ottobre, mentre c'è ancora tempo per alzarlo, invece che a novembre, quando l'unica opzione è guardarlo fallire in tempo reale.
Strumenti di test di carico e quanto costano realmente
Tre strumenti saltano fuori continuamente per questo lavoro: Apache JMeter, k6 e Gatling. JMeter è gratuito ed è ancora la risposta predefinita in molti team di QA aziendali, ma utilizzarlo correttamente richiede un ambiente abbastanza simile a quello di produzione per avere senso, generatori di carico che non siano il portatile di qualcuno e una bolletta che cresce con il traffico simulato.
k6, il motore di load testing di Grafana, risolve parte di quel problema. Il motore k6 è completamente open source con licenza AGPL-3.0 e gratuito per l'esecuzione locale illimitata, quindi puoi eseguire un numero qualsiasi di utenti virtuali sul tuo hardware senza alcun costo. Una singola macchina ben equipaggiata può solitamente gestire decine di migliaia di utenti virtuali da sola, il che copre la maggior parte dei negozi indipendenti.
Il costo emerge una volta che hai bisogno di scalare o posizioni di test distribuite. Grafana Cloud fattura k6 a $0.150 per ora di utente virtuale oltre un piano gratuito mensile di 500 ore. Prendi un test moderato: 500 utenti virtuali per 30 minuti, eseguiti due volte a settimana. Quell'esecuzione è di 250 ore di utente virtuale, e il mese totalizza 2,000 VUh. Fai i conti e Grafana Cloud k6 Pro arriva vicino a $244 al mese, il piano Team di Artillery Cloud addebita una cifra fissa di $199 indipendentemente dall'utilizzo, e il piano Team Enterprise di Gatling si converte in circa $413 al mese, sebbene il piano Team di Gatling consenta solo 5 ore di test al mese.
Scala il test verso qualcosa di più vicino a una prova generale reale per il Black Friday, diciamo 10,000 utenti virtuali per due ore, e il prezzo si muove con esso. Grafana Cloud k6 elenca a circa $0.15 per VU-ora sul suo livello Pro, che si traduce in circa $3,000 per 20,000 VU-ore. Quella singola corsa di prova può costare più di un mese di hosting, motivo per cui la maggior parte dei negozi testa una volta seriamente prima di novembre anziché ogni settimana.
Cosa testare per primo e in che ordine
Inizia con il flusso di checkout, non con la homepage. Una homepage che si carica lentamente infastidisce le persone; un checkout che fallisce fa perdere la vendita direttamente, quindi merita il primo test. Simula il percorso esatto che compie un acquirente: pagina prodotto, aggiungi al carrello, modulo indirizzo, passaggio di pagamento, pagina di conferma.
Testa il gateway di pagamento separatamente e in modalità sandbox prima di combinarlo con il resto del flusso. I fornitori di pagamento limitano le chiamate sandbox molto più aggressivamente rispetto al traffico live, e un test di carico che inonda la sandbox può far scattare quel limite e produrre falsi fallimenti che non hanno nulla a che fare con il tuo server. Esegui il test combinato completo due o tre settimane prima del Black Friday, non la settimana stessa, in modo che ci sia tempo per risolvere ciò che il test trova ed eseguirlo di nuovo.
Aumenta rapidamente il traffico simulato anziché gradualmente. Il traffico reale del Black Friday arriva in un'esplosione, attivato dall'invio di un'email o da un post social, non da una lenta salita nell'arco di un'ora. Un test che aumenta dolcemente nasconde l'esatta modalità di fallimento che stai cercando di catturare.
Dove si rompono realmente i siti WordPress
La maggior parte dei fallimenti di WordPress è riconducibile a uno dei tre limiti, nessuno dei quali si manifesta finché non arriva il picco di traffico. PHP-FPM, il gestore di processi che esegue PHP sulla maggior parte dei piani di hosting, limita il numero di richieste simultanee che gestirà in una sola volta. L'hosting condiviso economico e i piccoli piani VPS spesso impostano tale limite su una singola cifra, il che significa che il decimo visitatore che accede al sito nello stesso secondo semplicemente attende o va in timeout.
Il database racconta una storia simile. Sia MySQL che MariaDB limitano il numero di connessioni aperte, e un'installazione WordPress ricca di plugin può esaurire quel limite con il normale traffico da solo, prima ancora che arrivi un singolo visitatore guidato dallo sconto. I plugin di caching e le CDN aiutano enormemente, ma solo per le pagine che possono memorizzare nella cache. Un banner di vendita con un timer per il conto alla rovescia, un contatore di stock su una pagina di prodotto o un messaggio personalizzato "articoli rimasti" possono tutti forzare una pagina in modalità query di database completa non memorizzata nella cache nel momento esatto in cui il traffico raggiunge il picco.
Cosa sistemare prima e cosa può aspettare
Correggi prima il flusso di pagamento e di checkout. Questo è il passaggio in cui un fallimento costa direttamente denaro, ed è anche il passaggio in cui la maggior parte dei test di carico rivela problemi per la prima volta. Successivamente, aumenta i limiti dei worker PHP-FPM e i limiti delle connessioni al database, poiché entrambi sono solitamente una modifica della configurazione di una riga piuttosto che una migrazione.
Elementi dinamici come contatori di stock in tempo reale e timer per il conto alla rovescia possono attendere, o essere sostituiti con una versione memorizzata nella cache più semplice per il periodo dei saldi. Un semplice badge "quasi esaurito" che si aggiorna ogni pochi minuti costa molto meno in termini di capacità del server rispetto a un contatore dal vivo, e gli acquirenti raramente notano la differenza. Esegui un vero test di carico a ottobre, risolvi ciò che trova, quindi eseguilo di nuovo due settimane dopo per confermare che la soluzione abbia funzionato.
