Stress testing e Performance Audit
La fase di dimensionamento ottimale di una infrastruttura web ad alto traffico può non essere banale.
Capire quale sia la configurazione ottimale e il sizing delle risorse dipende infatti strettamente dall’applicativo ed è una attività che va testata sul campo.
Per rispondere a queste esigenze, neen propone due tipi di attività, spesso tra loro strettamente correlate.
Stress testing sull’applicativo
L’attività prevede di effettuare una installazione standard dell’applicativo su una infrastruttura similare a quella che si ipotizza necessaria in base ai dati attesi di traffico.
Quindi si definiscono uno o più pattern di navigazione (simulando il più possibile il comportamento di un utente reale – incluso post di form, login ecc.) e si lanciano tool di stress testing con N utenze a simulare la presenza sul sito di altrettanti navigatori attivi.
Il test può essere effettuato a partire da pochi utenti fino ad arrivare a decine di migliaia di utenti, anche con provenienza di più parti del mondo.
La finalità di uno stress testing può essere sia quella di verificare il comportamento dell’infrastruttura (load, velocità di risposta ecc.) con il numero di utenti e richieste al secondo target, sia quello di aumentare il numero di utenti fino ad individuare i limiti fisiologici dell’infrastruttura stessa.
Perché un solo test non è sufficiente e perché associare a questi test un Performance Audit?
Il comportamento di un applicativo dipende da molti fattori: dimensionamento dei server, configurazione e tuning degli application server e in primis dall’applicativo stesso.
Dopo una prima fase di test, viene quindi spontaneo effettuare un’analisi dei risultati sia a livello server, sia a livello applicativo, allo scopo di implementare tuning e migliorie e ri-effettuare i test.
L’attività di Performance Audit, non si limita quindi all’analisi dell’utilizzo dei parametri vitali del server durante il test di carico (CPU, Ram, I/O, Banda ecc.) ma effettua una “radiografia” approfondita del comportamento dell’applicativo, al fine di individuare quali componenti dello stesso utilizzano maggiori risorse in termini computazionali e/o di tempo di esecuzione.
Il risultato di un Performance Audit evidenzia quindi nel dettaglio sia a livello di linguaggio di scripting (php, .net ecc.) sia a livello di database quali siano i contesti a maggior criticità; un Performance Audit può arrivare a indicare singole query da modificare o specifiche funzioni del software da tunare.
“Oltre l’80% delle migliorie implementabili su una infrastruttura sono di origine applicativa”, sottolinea Marco Zani, CEO di neen. “E’ fondamentale, in caso si vogliano migliorare le prestazioni di un sito, lavorare a quattro mani con il team di sviluppo del cliente, per raggiungere l’obiettivo con migliorie su tutti i contesti possibili”.
Cicli di Audit e Stress testing
Quando si vuole raggiungere determinati risultati e KPI (key performance indicator) risulta evidente l’importanza di alternare alcuni cicli di:
stress test -> performance audit -> tuning -> nuovi stress test
al fine di verificare i risultati sul campo delle migliorie e dei tuning messi in atto.
Dal momento che non c’è limite all’ottimizzazione, l’attività si chiude quando si sono raggiunti i risultati desiderati o quando il trade off economico tra sforzi e migliorie è troppo sbilanciato.
Performance Audit? Non solo in fase di test e staging
Abbiamo descritto l’attività di performance Audit come logica conseguenza di un’analisi di dimensionamento, ma questo tipo di attività è assolutamente sensata e percorribile anche sull’applicativo in produzione.
I test per quanto realistici, non potranno mai replicare il mondo reale.
Inoltre dopo la messa online, gli applicativi evolvono, spesso si riscontrano rallentamenti inattesi o semplicemente nasce l’esigenza di ottimizzazione.
I tool utilizzati per l’analisi sono assolutamente compatibili con sistemi in produzione, vengono attivati per periodi limitati al fine di consentire la raccolta dati necessaria.
