Come ho misurato il limite di carico di un e-commerce
Metodo di prova
Origine isolata, CDN esclusa, miscela di pagine dichiarata, frequenza di arrivo costante e soglie di latenza, errori e iterazioni perse fissate prima del test.
La domanda era quanto carico reggesse l’origine di un e-commerce e quale componente cedesse per primo. La prova si è svolta su un VPS isolato, dismesso dopo il test. Il server che oggi ospita il negozio non è stato sottoposto a stress test.
Una prova che misura l’origine
Ho usato k6 da una macchina separata, a frequenza di arrivo costante. Ogni iterazione chiedeva una pagina HTML: home, categoria, prodotto o ricerca, con una miscela fissata prima della prova. La CDN era esclusa, le cache erano calde e il bersaglio rispondeva con il certificato e il nome HTTPS corretti. L’ambiente di prova bloccava email e chiamate esterne; non sono stati creati ordini né inviati pagamenti.
I criteri erano scritti prima di salire di carico: p95 sotto 3 secondi, meno dell’1% di risposte invalide e zero iterazioni perse. I gradini duravano 60 secondi e si fermavano al primo fallimento. Separatamente, le prove di tenuta duravano 10 minuti. Durante la prova ho campionato CPU e stato di PHP-FPM; il profiling PHP era attivato solo su richieste selezionate, fuori dal benchmark k6.
La soglia osservata
Nella configurazione finale, 3 richieste HTML al secondo hanno retto per 10 minuti: 1.802 richieste contando il preflight, p95 di 1,102 secondi, nessuna risposta invalida e nessuna iterazione persa. La CPU media campionata era al 66,41%.
Il gradino breve a 5 richieste al secondo ha superato i criteri, ma la CPU era circa al 96%: quasi nessun margine. A 6 richieste al secondo le risposte completate erano valide, ma la latenza ha superato il limite. Il profiling ha indicato il lavoro PHP come principale vincolo osservato; le modifiche mirate sono state confrontate con prove di tenuta appaiate, senza sommare i loro miglioramenti come se fossero una garanzia unica.
La frontiera dei gradini brevi è passata da 4 superati e 5 falliti nella prova iniziale a 5 superati e 6 falliti nella configurazione finale. I gradini erano interi e il traffico aveva una componente casuale: questo non dimostra un aumento percentuale preciso della capacità.
Limiti
La configurazione finale non è stata tenuta per 10 minuti a 5 richieste al secondo. Una precedente prova lunga a quel carico usava una modifica ai file di un plugin poi ritirata e non certifica il risultato finale. Non è stato eseguito alcuno stress test sul server di produzione.
Le cifre contano richieste HTML all’origine, non clienti simultanei, caricamenti completi nel browser o ordini. Il test non eseguiva transazioni di checkout né includeva le attività di fondo della produzione. La soglia operativa del server attuale richiede una nuova prova su un ambiente isolato che lo rappresenti.
Caso anonimizzato su richiesta del cliente.