Prima di lanciarlo: dove e con quale permesso
Cosa misurate, e perché non è «quanti utenti»
La domanda giusta non è «quanti utenti regge» ma «a partire da quanti utenti i tempi di risposta smettono di essere accettabili». Un sistema non passa da «va bene» a «è caduto» in un istante: prima rallenta. Il test serve a trovare il punto in cui il rallentamento diventa inaccettabile — quello, non il momento del crollo, è la vostra capacità utile.
- il tempo di risposta sotto cui sta il 95% delle richieste: molto più onesto della media, che nasconde i casi peggiori
- p95il tempo di risposta sotto cui sta il 95% delle richieste: molto più onesto della media, che nasconde i casi peggiori
- la quota di errori oltre la quale il test dice che il punto di rottura è vicino
- < 1%la quota di errori oltre la quale il test dice che il punto di rottura è vicino
- il punto in cui la curva dei tempi svolta verso l'alto: è lì la capacità reale
- il ginocchioil punto in cui la curva dei tempi svolta verso l'alto: è lì la capacità reale
La legge di Little: perché il crollo è improvviso
C'è una ragione matematica per cui i sistemi non degradano dolcemente. La legge di Little dice che il numero medio di richieste presenti nel sistema è uguale al ritmo con cui arrivano moltiplicato per il tempo che ciascuna passa dentro. Finché il tempo di risposta è basso, la coda resta corta. Ma appena il sistema si satura il tempo di risposta sale, e siccome moltiplica il ritmo d'arrivo, la coda si allunga, il che allunga ancora i tempi: è una spirale. Ecco perché oltre una certa soglia bastano pochi utenti in più per far passare tutto da lento a fermo.
L = λ × W — il numero di richieste nel sistema è il ritmo di arrivo per il tempo di permanenza.
Legge di Little (teoria delle code)
Il primo test con k6, in pratica
k6 è uno strumento gratuito e open source pensato apposta per questo. Il test si descrive in un piccolo file: si dice quale indirizzo chiamare e come far salire il numero di utenti virtuali nel tempo. L'idea del primo test è una rampa: si parte da pochi utenti e si sale a gradini, tenendo d'occhio quando i tempi di risposta escono dalla soglia che avete deciso accettabile.
- 01
Decidete la soglia accettabile, prima di partire
Per esempio: il 95% delle richieste deve stare sotto 800 millisecondi e gli errori sotto l'1%. Scriverla prima evita di adattare il giudizio al risultato dopo.
- 02
Scegliete un percorso realistico
Non solo la home. Il percorso che conta è quello che fa lavorare il sistema: la ricerca, l'aggiunta al carrello, l'apertura di una scheda che interroga il database. Un test sulla sola home misura la pagina più leggera che avete.
- 03
Impostate una rampa a gradini
Fate salire gli utenti virtuali per fasi — per esempio 50, poi 100, poi 200, poi 400 — con qualche minuto per gradino. Vi serve vedere come cambia il comportamento salendo, non solo il picco.
- 04
Lanciate e guardate la curva dei tempi
Mentre gli utenti salgono, il tempo di risposta p95 all'inizio resta piatto. A un certo punto svolta verso l'alto. Quel punto — il ginocchio — è la vostra capacità reale.
- 05
Confrontatelo con il traffico che vi aspettate
Se il ginocchio è a 300 utenti insieme e nel picco più alto dell'anno ne avete 120, dormite tranquilli. Se è a 300 e la campagna in tv ve ne porterà un migliaio nello stesso minuto, avete appena scoperto una cosa importante con settimane di anticipo.
Come leggere il risultato senza ingannarsi
| Cosa vedete | Cosa significa |
|---|---|
| I tempi restano piatti fino alla fine della rampa | Non avete trovato il punto di rottura: il test era troppo leggero, rilanciate spingendo più su |
| I tempi salgono dolcemente e in modo costante | Il sistema scala bene nell'intervallo provato: buon segno |
| I tempi svoltano di colpo verso l'alto | Avete trovato il ginocchio: quello è il numero da ricordare |
| Compaiono errori prima che i tempi salgano | Qualcosa si rompe per motivi non di velocità (connessioni al database esaurite, limiti di configurazione): va indagato a parte |