Prima di acquistare hardware più potente conviene capire dove si perde il tempo. Un metodo semplice per leggere le metriche di prestazione.
Quando un'applicazione rallenta, la reazione più frequente è aggiungere risorse: più memoria, più core, un server nuovo. A volte funziona, più spesso sposta il problema o lo nasconde per qualche mese. Prima di spendere conviene stabilire dove il tempo viene effettivamente perso.
Quattro risorse, un solo colpevole alla volta
In quasi ogni sistema il rallentamento dipende da una di quattro risorse: calcolo, memoria, disco o rete. Il collo di bottiglia è quella che arriva per prima al limite mentre le altre restano sotto utilizzate. Misurarle nello stesso intervallo, con lo stesso carico, è il passaggio che evita le interpretazioni a intuito.
I falsi amici delle medie
Un utilizzo medio della CPU al 35% può convivere con picchi di cinque minuti al 100% proprio negli orari critici. Le medie sono utili per la capacità, i percentili per l'esperienza degli utenti. Allo stesso modo, una latenza di rete bassa in rete locale non dice nulla sul percorso verso un servizio esterno.
Il caso opposto: l'eccesso di capacità
Esiste anche l'errore inverso. Macchine virtuali dimensionate «per sicurezza» e mai riviste occupano risorse e licenze che potrebbero servire altrove. Un'analisi dei consumi reali su 30-60 giorni mostra in genere dove si può ridurre senza rischi e dove invece la capacità è davvero al limite.
Regola utile: un intervento di ottimizzazione dovrebbe sempre poter essere descritto con una frase del tipo «riduce il tempo di X da A a B», verificabile prima e dopo.
Il risultato di questo lavoro non è una lista di acquisti, ma una mappa delle priorità: cosa correggere nella configurazione, cosa riorganizzare e cosa, eventualmente, potenziare.
