Quando si creano sistemi software di gestione, generalmente (e semplificando) si sviluppano considerando le seguenti fasi: progettazione diagramma entità relazione, dimensionamento del database, progettazione esperienza utente, creazione interfacce utente, creazione procedure di estrazione/stampa, sviluppo interfacce di applicazione (API), dimensionamento del sistema di produzione, rilascio in produzione.
Se tutto è stato fatto a regola d’arte, il software risponderà alle esigenze del committente ed il committente potrà iniziare ad usarlo per i propri scopi. Fin qui tutto bene.
Con il trascorrere del tempo, il software comincia ad essere utilizzato, il committente inserisce i dati 10,100,1000,10.000 anagrafiche, aumentano gli utenti 10,50,100 aumentano le applicazioni che accedono ai dati attraverso le sue API, viene creata una sezione pubblica in internet (o era già un sistema pubblico in internet) e… le prestazioni poco per volta peggiorano; magari non peggiorano le prestazioni dell’intera applicazione, ma solo per alcune funzionalità, alcune procedure.
Ok, non c’è problema! Aumentiamo la ram, raddoppiamo i core della cpu, clusterizziamo l’applicazione! (se è predisposta per poterlo fare!). Sì, possiamo correre ai ripari con questo approccio, ma non è il modo migliore per risolvere il problema; un approccio migliore è sicuramente capire in modo più preciso dove si nasconde il problema.
Il sistema software è appunto un sistema, che è composto da più elementi: l’applicazione, l’application server, il web server, il database server, il browser; ognuno di questi elementi potrebbe essere un “collo di bottiglia” che deteriora le prestazioni della nostra applicazione (senza contare gli elementi esterni al dominio applicativo quali traffico di rete o velocità di accesso al disco ecc…).
Raccogliere in primis ed analizzare successivamente, i dati del nostro “stack” applicativo, è uno degli strumenti migliori che ci possono aiutare a capire dove agire per migliorare le prestazioni, a che livello ci sono più (o meno) problemi.
Per i nostri progetti software, le metriche che raccogliamo per monitorare le performance applicative sono :
- tempo di risposta dell’applicazione
- numero di richieste effettuate all’applicazione
- tempo di esecuzione delle query al database
- dimensione delle risposte dell’applicazione
Le informazioni raccolte, vengono inviate ad un server di monitoraggio che archivia i dati per l’analisi. Il server che abbiamo scelto per monitorare le informazioni è Zabbix server che oltre ad archiviare i dati ed analizzarli, permette anche la configurazione di eventi al generarsi di certe condizioni: in questo modo possiamo anche essere avvisati preventivamente nel momento in cui un evento di “caduta di prestazione” viene rilevato.
Naturalmente le metriche che si dovrebbero rilevare dipendono dal sistema applicativo che si sviluppa, quindi possono cambiare da applicazione ad applicazione; devono comunque essere funzionali al monitoraggio delle prestazioni.
Anche il modo in cui viene sviluppata l’applicazione può essere più o meno funzionale alla raccolta delle metriche; utilizzare framework applicativi strutturati aiuta la creazione di elementi dedicati alla raccolta delle misure che si vogliono rilevare, in particolare l’implementazione che abbiamo sviluppato è per il framework MVC Ruby on Rails.
Creando un middleware dedicato alla raccolta delle informazioni ed all’invio dei dati al server Zabbix, siamo in grado di misurare il comportamento dell’applicazione.