Introduzione ai performance monitoring tool

Come indagare le cause di un problema di performance?

Nella precedente serie di articoli:

abbiamo parlato dei test di performance dell’ERP Web.UP. Ci siamo in particolare focalizzati sul sistema realizzato per effettuare test di carico, di stress o di endurance su Web.UP così come abbiamo trattato dei test di non regressione delle performance.

Tutti questi test sono in grado di avvertire gli sviluppatori sulla presenza di un problema di performance, problema che può presentarsi sotto diverse forme:

tempi di esecuzione peggiorati nel tempo
timeout di processi o blocco dell’intero sistema in presenza di un determinato carico di utenti o dopo un certo periodo di tempo dallo start del sistema

Il fatto di eseguire tali test aiuta ad accorgersi del problema in una fase preventiva a quella del passaggio in produzione e permette quindi la possibilità di risolverlo prima che si verifichi direttamente dal cliente.

Ma tali test non fanno altro che allertare che ad esempio il determinato processo X che ci si aspettava impiegasse N unità di tempo ne impiega invece più di N. Oppure avvertono che il sistema sotto test ha generato degli errori di timeout o si è bloccato totalmente o su alcuni processi.

A questo punto come si possono indagare le cause di tali problemi e correggerle? Esistono dei performance monitoring tool o delle tecniche che possono aiutare nell’analisi e nella risoluzione dei casi critici?

In questa serie di articoli parleremo degli strumenti che possono aiutare in tale indagine, che indicheremo col termine generale performance monitoring tool e del loro utilizzo in Sme.UP ERP.

Definizione e caratteristiche dei performance monitoring tool

Un tool di monitoring delle performance è uno strumento che ha l’obiettivo di monitorare le performance di un’entità tecnologica, che può essere ad esempio un’infrastruttura, un server, un’applicazione, una pagina web…

Per le applicazioni web si usa spesso il termine APM (application performance monitor o anche manager), ovvero tool che monitora un’applicazione e le sue dipendenze.

Sul mercato esistono una miriade di soluzioni già pronte di monitoring di performance, per tutte le tecnologie e per tutti i gusti e budget. Alcuni richiedono configurazioni complesse e anche modifiche al codice altri invece sono più facili da installare e poco intrusivi. Essi appunto possono operare su uno o più diversi livelli di uno stack tecnologico, ad esempio esistono tool di monitoring dell’infrastruttura, dei server, degli utenti, delle transazioni individuali, degli accessi ai database, del codice, ecc… Generalmente è necessario utilizzare più di uno di questi tool per indagare le cause di problemi prestazionali della propria applicazione e tali soluzioni già pronte possono in situazioni complesse non essere comunque sufficienti a poter individuare precisamente cosa genera il problema.

Nel caso di smeup all’utilizzo in laboratorio di tool di performance monitoring reperiti sul mercato si affiancano strumenti di monitoraggio sviluppati ad hoc. Il sistema smeup infatti consiste di più layer applicativi realizzati utilizzando tecnologie diverse: applicazioni web o desktop differenti mentre il livello più interno è quello che fa capo al sistema IBMi. Fulcro del sistema smeup sono le cosiddette FUN, funzioni applicative la cui risoluzione viene chiesta dal client più esterno, nel caso web Web.UP, al livello IBMi, passando dall’intermediario Sme.UP Provider. Sistemi di monitoraggio custom specifici sulle FUN sono ad esempio utili nella realtà smeup per poter comprendere in dettaglio l’origine dei rallentamenti del sistema.

Si fa notare che i performance monitoring tool sono strumenti usati non solo durante le fasi di testing (ad esempio testing di performance del software) ma nascono per essere utilizzati anche in produzione, in maniera tale da avvertire tempestivamente di problemi reali sui sistemi dei clienti e di aiutare nell’individuazione di anomalie. Il monitoraggio porta però un overhead sulle applicazioni e sull’infrastruttura, perché oltre a dover essere eseguito il codice di produzione devono essere registrate e analizzate informazioni utili al monitoraggio. Tali operazioni aggiuntive possono incidere negativamente sulle performance. Bisogna quindi essere molto cauti nell’utilizzo di tali strumenti in produzione. Spesso è il caso di abilitarli solo temporaneamente o su utenti definiti e comunque bisogna porre molta attenzione all’overhead da loro dichiarato e prodotto.

Chiara Zambelli
Responsabile CI/CD – smeup
My LinkedIn Profile