Prestazioni e continuità operativa
Prove di carico: misurare la capacità dei processi software aziendali
Sapere quante richieste al secondo risponde un servizio è utile soltanto se quel numero descrive il lavoro che l’impresa deve completare. Un processo può attraversare più chiamate, attendere una coda e restituire una conferma prima che l’elaborazione sia davvero conclusa. Una prova di carico ben progettata collega quindi pressione sul sistema, tempi operativi e correttezza degli esiti. Il suo obiettivo è costruire evidenze sulle condizioni di funzionamento e sui limiti, così che le decisioni di capacità derivino da scenari riconoscibili e ripetibili.
Descrivere il lavoro prima di contare gli utenti
Il numero di utenti collegati non determina da solo il carico. Alcuni consultano informazioni, altri importano file o producono elaborazioni pesanti. Per costruire uno scenario serve identificare le operazioni, la loro frequenza e le relazioni tra i passaggi. Si distingue il tempo di interazione umana dal tempo impiegato dal software, mantenendo le attese che il processo prevede davvero. Ripetere senza pausa tutte le chiamate può creare una pressione artificiale; inserire attese arbitrarie può invece nascondere un limite importante.
Consideriamo un esempio esclusivamente illustrativo: al termine della giornata un’applicazione riceve un insieme di ordini, verifica disponibilità e prepara documenti. Il gruppo dovrebbe descrivere quanti ordini arrivano, quante righe contengono e quali elaborazioni vengono avviate per ciascuno. Vanno inclusi anche gli utenti che continuano a lavorare durante il picco. L’obiettivo non è riprodurre ogni attività possibile, ma costruire una combinazione motivata che rappresenti il rischio da valutare. Le ipotesi devono essere riconoscibili e confrontabili con osservazioni successive.
Scegliere un modello di arrivo coerente con la domanda
La documentazione Grafana k6 distingue modelli chiusi e aperti. Nei primi, la durata di un’iterazione influenza l’avvio di quella successiva; nei secondi, gli avvii vengono pianificati indipendentemente dal completamento. Se il sistema rallenta, un modello chiuso può ridurre il ritmo delle nuove operazioni. Questo è rilevante quando si vuole misurare una domanda che continua ad arrivare anche in presenza di ritardi: il generatore rischierebbe di alleggerire il servizio proprio mentre dovrebbe mostrarne la difficoltà.
Nel nostro esempio, l’importazione degli ordini da un canale esterno può richiedere un modello di arrivo indipendente, mentre un operatore che attende una conferma prima di proseguire presenta una dinamica diversa. I due comportamenti possono convivere nello stesso progetto di prova. La scelta va dichiarata insieme alla domanda iniziale: stiamo valutando una popolazione di operatori interattivi oppure la capacità di assorbire un flusso in ingresso? Il modello deve permettere di rispondere a quella domanda, e il generatore deve avere risorse sufficienti per sostenerlo.
Preparare dati e ambiente che rendano interpretabile la misura
Un ambiente vuoto può produrre tempi molto diversi da uno che contiene anni di documenti. Conta anche la distribuzione dei valori: cercare sempre lo stesso cliente può favorire la cache, mentre usare un’identità nuova a ogni chiamata può introdurre un comportamento altrettanto poco rappresentativo. È utile predisporre dati sintetici con volumi, relazioni e concentrazioni motivate. Nell’esempio degli ordini, pochi articoli molto richiesti potrebbero generare contesa diversa rispetto a un insieme in cui ciascuna operazione coinvolge prodotti distinti.
Il rapporto di prova deve descrivere risorse assegnate, configurazione, versioni e differenze rispetto all’ambiente di esercizio. Anche servizi simulati e limiti delle dipendenze esterne vanno dichiarati. Sostituire un servizio remoto con una risposta immediata può isolare un componente, ma non dimostra la capacità del percorso completo. Le prove si eseguono in ambienti e finestre autorizzati, con dati e destinazioni controllati. Occorre impedire che una simulazione generi invii reali, documenti operativi o addebiti verso servizi collegati.
Definire soglie sul completamento e sulla correttezza
Prima della prova occorre concordare che cosa costituisca un esito accettabile. k6 permette di esprimere soglie sulle metriche per determinare il successo o il fallimento dell’esecuzione. La selezione delle misure resta però responsabilità del progetto. Una risposta rapida che registra soltanto la presa in carico non rappresenta il tempo di completamento del processo. Nel caso illustrativo, si dovrebbero distinguere accettazione dell’ordine, verifica conclusa e documento pronto, evitando di aggregare questi momenti in un unico indicatore ambiguo.
Le soglie devono comprendere errori e risultati mancanti, oltre alle latenze. Se il sistema completa rapidamente una parte degli ordini e perde gli altri, la sola velocità dei successi restituisce un quadro ingannevole. È opportuno conservare il numero delle intenzioni inviate, degli esiti confermati e dei casi da riconciliare. I percentili possono mostrare la coda dei tempi, ma richiedono campioni sufficienti e una definizione precisa della popolazione. Tempi di richieste fallite o interrotte non dovrebbero sparire dalla lettura complessiva della prova.
Aumentare la pressione e distinguere il limite dalla causa
Una sequenza graduale aiuta a riconoscere quando il comportamento cambia. Si può iniziare da un carico ridotto, verificare gli script, stabilizzare un livello rappresentativo e osservare incrementi successivi. Per ogni fase vanno mantenuti durata, quantità di lavoro e condizioni di arresto. Un picco breve risponde a una domanda diversa da una pressione sostenuta: il primo può rivelare un’insufficienza momentanea, la seconda accumuli di risorse, code o rallentamenti progressivi. Le prove devono essere scelte secondo il problema, con un limite operativo conosciuto.
Quando aumenta la latenza, la metrica descrive un effetto. La diagnosi richiede di correlare richieste, attese del database, connessioni, memoria, attività dei lavoratori e risposte delle dipendenze. Anche la macchina che genera il carico può diventare il collo di bottiglia. Nell’esempio degli ordini, una coda crescente con lavoratori poco occupati suggerisce domande diverse da una coda crescente con risorse sature. La prova dovrebbe raccogliere informazioni sufficienti a scegliere il prossimo esperimento, senza attribuire automaticamente ogni ritardo al componente più visibile.
Misurare il recupero dopo la fine del picco
La prova non termina quando il generatore smette di inviare richieste. Un sistema può avere accettato più lavoro di quanto ne riesca a completare entro un tempo utile. Si osserva quindi quanto impiega a smaltire l’arretrato, se ripristina i tempi ordinari e se lascia operazioni in uno stato incerto. Nel caso illustrativo, gli ordini ancora in attesa devono restare identificabili e riconciliabili. La riduzione della coda non dimostra da sola il successo: potrebbe dipendere anche da scarti, scadenze o errori permanenti.
Il recupero va valutato insieme alla correttezza dei dati. Si confrontano richieste previste, operazioni completate ed eventuali ripetizioni, controllando i vincoli rilevanti per il processo. Se i tentativi automatici amplificano la pressione dopo un rallentamento, il progetto deve rivederne tempi e limiti. Le condizioni di arresto proteggono l’ambiente di prova e mantengono l’esperimento leggibile. Interrompere un test per una soglia concordata è un risultato da analizzare; proseguirlo senza controllo può rendere più difficile capire quale evento abbia innescato il degrado.
Trasformare il risultato in una decisione ripetibile
Un rapporto utile collega scenario, versione, dati, misure e limiti. La conclusione dovrebbe specificare sotto quali condizioni il processo ha rispettato i criteri e dove siano emerse incertezze. Per confrontare una modifica architetturale, si mantiene un riferimento stabile oppure si dichiarano le differenze che impediscono il confronto diretto. Un grafico migliore non basta se il secondo test ha usato documenti più piccoli, cache già preparate o risorse maggiori. Le ipotesi rimaste aperte diventano attività di approfondimento, con responsabile ed evidenza attesa.
Queste prove sostengono la progettazione tecnica; la valutazione degli impegni di servizio richiede anche un confronto contrattuale e operativo. Per quel contesto è pertinente la guida di Gestionale sul Web su SLA, RTO, RPO ed exit strategy del gestionale cloud. Il test di capacità conserva un compito specifico: mostrare come un processo si comporta nelle condizioni provate. Non promette prestazioni universali, ma permette al gruppo di pianificare interventi e ripetere le misure quando cambiano codice, dati o domanda.
Riferimenti tecnici
Per approfondire i temi tecnici trattati:
- Grafana k6: modelli aperti e chiusi delle prove di carico
- Grafana k6: soglie e criteri di successo delle prove
Analisi metodologica originale. Lo scenario degli ordini è illustrativo e non riporta prove, prestazioni o architetture di clienti e di Gestionale sul Web. Nessuna prova di carico è stata eseguita sui siti pubblici per scrivere questo articolo.
A cura della redazione tecnica SoftJob. Pubblicato il .