Il modello “Disastro del successo”.

Il momento più pericoloso per una startup non è il fallimento. È un successo. Immagina questo scenario: Lanci una nuova campagna di marketing. Oppure vieni messo in evidenza su TechCrunch. Oppure un influencer con 5 milioni di follower pubblica post sul tuo prodotto. Il traffico aumenta di 100 volte durante la notte. Sei pronto a guadagnare milioni. E poi… il sito si carica bianco. 504 Timeout gateway. Servizio 503 non disponibile. La CPU del tuo database raggiunge il 100%. Il tuo pool di connessioni è esaurito. Gli utenti aggiornano la pagina, aggiungendo altro carico. Il sistema entra in una spirale mortale. Vai nel panico. Provi ad aggiornare il database su AWS, ma sono necessari 30 minuti per l’applicazione. Quando il sito viene ripristinato, il traffico è scomparso. Gli utenti sono arrabbiati. La reputazione è danneggiata.

Questo è un disastro di successo. Hai avuto successo in Marketing, ma hai fallito in Ingegneria. Il Test di carico impone che questo scenario si verifichi in un ambiente controllato, giorni o settimane prima dell’evento reale. Simuliamo l’incidente. Troviamo il collo di bottiglia. Lo aggiustiamo. Ripetiamo.

Perché Maison Code ne parla

Noi di Maison Code siamo specializzati nell’e-commerce “Alta Pressione”. I nostri clienti non sono tipici blog. Sono marchi che lanciano scarpe da ginnastica in edizione limitata alle 10:00. Passano da 0 visitatori a 50.000 visitatori in 3 secondi. Abbiamo imparato attraverso l’esperienza che La scalabilità non è magica; è matematica. Se non hai testato il tuo sistema a 10 volte il carico previsto, non disponi di un sistema robusto; hai una preghiera. Ne scriviamo perché vogliamo salvare i fondatori dal dolore di vedere il loro “Grande Momento” trasformarsi in un’interruzione pubblica.

Lo strumento: k6 (Grafana)

Per molto tempo lo standard è stato JMeter. Era potente ma doloroso (GUI basata su XML). Poi Locust (Python) divenne popolare. Ma oggi lo standard del settore è k6. Perché k6?

JavaScript: i test sono scritti in JS/TS. Gli sviluppatori si sentono a loro agio.
Prestazioni: il motore è scritto in Go. Un laptop può simulare 30.000 utenti simultanei.
CI/CD: funziona facilmente in una pipeline di azioni GitHub.
Metriche: si integra nativamente con Grafana/InfluxDB per una splendida visualizzazione in tempo reale.

Implementazione: scrivere uno script k6

Diamo un’occhiata a uno script di test di carico robusto.

importa http da 'k6/http';
importa {sonno, controlla} da 'k6';

// Configurazione: il profilo di carico
opzioni const esportazione = {
  fasi: [
    { durata: '30s', target: 20 }, // Aumenta fino a 20 utenti (riscaldamento)
    {duration: '1m', target: 50 }, // Aumenta fino a 50 utenti (Caricamento)
    { durata: '2 minuti', target: 50 }, // Rimani a 50 utenti (sostentamento)
    { durata: '30s', target: 100 }, // Picco a 100 utenti (Stress)
    { durata: '30s', target: 0 }, // Rampa di discesa (raffreddamento)
  ],
  soglie: {
    // Condizioni di fallimento
    http_req_failed: ['rate<0.01'], // Il tasso di errore deve essere < 1%
    http_req_duration: ['p95<500'], // il 95% delle richieste deve essere < 500 ms
  },
};

funzione predefinita di esportazione () {
  const BASE_URL = 'https://staging.maisoncode.paris';
  
  // 1. Visita la home page
  const resHome = http.get(BASE_URL);
  check(resHome, { 
    'Stato home 200': (r) => r.status === 200,
    'Ritorno veloce': (r) => r.timings.duration < 200, 
  });
  
  dormire(1); // L'utente pensa...

  // 2. Ricerca del prodotto (uso intensivo della CPU)
  const resSearch = http.get(`${BASE_URL}/api/search?q=shirt`);
  check(ricerca, { 
    'Stato ricerca 200': (r) => r.status === 200 
  });

  dormire(2);
}

I 4 tipi di test delle prestazioni

Comprendi la differenza, altrimenti proverai la cosa sbagliata.

Test del fumo:
- Obiettivo: garantire che il sistema gestisca un carico minimo.
- Carico: 1-5 utenti virtuali (VU).
- Quando: dopo ogni distribuzione. “Abbiamo rotto completamente il server?”
Test di carico:
- Obiettivo: verificare che il sistema gestisca il traffico previsto.
- Carico: il traffico medio del tuo sito di produzione (ad esempio, 50 VU).
- Quando: Prima delle versioni minori.
Test da sforzo:
- Obiettivo: trovare il punto di rottura.
- Carica: aumenta all’infinito finché il sistema non si blocca.
- Risultato: “Possiamo gestire 2.500 utenti. A 2.501 il DB si blocca.”
- Quando: Prima di importanti modifiche architettoniche.
Test di assorbimento:
- Obiettivo: trovare perdite di memoria.
- Carico: carico moderato (80% della capacità) per 24 ore.
- Risultato: “Ah, l’utilizzo della memoria aumenta dell’1% ogni ora. Abbiamo una perdita.”

Identificazione dei colli di bottiglia

Hai trovato il punto di rottura. Ora chiediti Perché? Il “perché” raramente è il codice stesso. Di solito è l’infrastruttura.

Il database (il solito sospetto):
- Esaurimento connessione: “FATAL: gli slot di connessione rimanenti sono riservati ai ruoli di superutente non di replica”.
  - Correzione: Pooling delle connessioni (PgBouncer).
- Saturazione CPU: query complesse che eseguono scansioni complete della tabella.
  - Correzione: Indicizzazione. Leggi le repliche. Utilizza Redis per memorizzare nella cache le query comuni.
Ponti (API):
- Il tuo sito è veloce, ma chiami l’API di spedizione per calcolare le tariffe.
- L’API di spedizione scade sotto carico.
- Le tue richieste sono in coda in attesa dell’API di spedizione.
- Il tuo server esaurisce la RAM.
- Correzione: Timeout. Interruttori automatici.
Il ciclo degli eventi (Node.js):
- Il nodo è a thread singolo. Se esegui calcoli pesanti sulla CPU (crittografia, ridimensionamento delle immagini) sul thread principale, blocchi tutti gli utenti.
- Correzione: scaricamento su thread di lavoro o funzioni serverless.

La semantica dei percentili (p95, p99)

Non giudicare mai le prestazioni in base alla Media. Le medie nascondono bugie.

Utente A: 100ms
Utente B: 100ms
Utente C: 10.000 ms (10 secondi)
Media: ~3,4s. (Sembra ok).
p99: 10 secondi. (Terrificante).

p95 (95° percentile) significa: “Ignora i valori anomali del 5% più lenti. Qual è la velocità per tutti gli altri?” p99 (99° percentile) significa: “L’esperienza dell’1% delle richieste più lente.”

Perché p99 è importante: Nell’e-commerce, le “richieste più lente” sono spesso gli utenti con i Carrelli più grandi. Utente con 1 elemento -> Query veloce. Utente con 50 elementi -> Query lenta. L’utente p99 è il tuo Cliente di alto valore. Se ignori p99, stai ottimizzando per gli acquirenti delle vetrine e ignorando le balene.

Test in produzione?

PERICOLO. Eseguire uno stress test sulla produzione è rischioso.

Sbagli Analytics: Google Analytics mostrerà 10.000 visite “bot”, rovinando i tuoi dati di marketing.
Attiva i costi: se utilizzi Serverless/Vercel, pagherai per i 10 milioni di richieste che hai appena inviato spam.
Avvisi di frode: Stripe potrebbe bannarti per modelli di attacco di “test delle carte”.

La regola d’oro: utilizzare un ambiente di staging con parità di dati. Lo staging deve essere identico a Prod (stessa dimensione dell’istanza AWS, stessa dimensione del DB). Se Staging è un piccolo t2.micro e Prod è un enorme m5.large, i risultati del test non hanno senso.

14. Ingegneria del caos (rompere le cose di proposito)

Scollegare il cavo del database. Che succede? Il sito si blocca? Oppure mostra una versione memorizzata nella cache? Utilizziamo Chaos Mesh o script generici Pumba per uccidere i contenitori in modo casuale durante il test di carico. Se 1 replica muore, il sistema di bilanciamento del carico dovrebbe reindirizzare immediatamente. Se la cache Redis muore, il database dovrebbe farsi carico (o prendere fuoco). Sapere questo prima delle 9:00 del giorno del lancio non ha prezzo.

15. Test di carico basato su browser (browser k6)

I test del protocollo (HTTP) non eseguono il rendering di JavaScript. Non rilevano “Errori di idratazione” o “Ritardo di rendering della reazione”. Il browser k6 avvia istanze reali di Chrome Headless. Misura il CLS (Cumulative Layout Shift) e il FID (First Input Delay) sotto carico. “Il server è veloce (API da 200 ms), ma il client è lento (esecuzione JS di 3 secondi) perché abbiamo inviato 5 MB di JSON.” Solo il test del browser lo rivela.

16. Automatizzazione dei test di carico in CI/CD (azioni GitHub)

Non eseguire k6 dal tuo laptop. Eseguilo su ogni richiesta pull. Aggiungiamo un flusso di lavoro load-test.yml.

Distribuire il ramo all’URL di staging.
Esegui k6 run smoke-test.js (controlla 500 secondi).
Se fallisce, blocca l’unione. Ciò impedisce “regressioni delle prestazioni”. “Il Junior Dev ha aggiunto un ciclo di query N+1. Il test lo ha rilevato perché la latenza è passata da 200 ms a 2000 ms.”

17. Spike Test e Soak Test

Conosci la differenza. Test di picco:

Simula uno “Sneaker Drop” o un “annuncio del Super Bowl”.
0 -> 10.000 utenti in 10 secondi.
Obiettivo: testare i trigger di scalabilità automatica (i server AWS si avviano abbastanza velocemente?). Soak Test:
Simula il “fine settimana del Black Friday”.
Carico elevato per 48 ore.
Obiettivo: testare le perdite di risorse (memoria, spazio su disco, descrittori di file). Hai bisogno di entrambi.

18. Conclusione

La performance non è “bello da avere”. È una caratteristica. La scalabilità non è magica. È ingegneria. Il test di carico è la disciplina di convalida della tua ingegneria. Non aspettare il blackout. Rompi tu stesso la lampadina, mentre ne hai una di riserva in tasca.

Ti stai preparando per il Black Friday?

Non aspettare fino a novembre. Maison Code offre servizi di “Stress Testing delle Infrastrutture”. Simuliamo picchi di traffico 100x, identifichiamo i colli di bottiglia e implementiamo policy di auto-scaling che funzionano.

Contattaci per salvaguardare le tue entrate.

Prevedi un traffico elevato?

Eseguiamo test di carico e stress utilizzando k6 per convalidare la capacità dell’infrastruttura e verificare le politiche di auto-scaling. Assumi i nostri architetti.