Una volta sistemato il problema, la transazione è stata provata nell’ambiente di test monitorato da Dynatrace Application Monitoring mostrando un miglioramento significativo grazie alla comparazione dei risultati fatta dalla soluzione Dynatrace analizzando le cpu. Tutto questo dimostrato che la nuova release era pronta per passare in produzione, dove fin da subito ha mostrato come era in grado di ripercuotersi sui risultati. Ecco come i miglioramenti apparivano dal punto di vista degli utenti reali finali:
Il caso si è chiuso ottenendo un successo clamoroso: un tempo di risposta per la transazione commerciale più importante ridotto da 13,3 secondi e circa 4 secondi, con transazioni aderenti agli SLA nella misura del 90%, rispetto al precedente 11,8%. Tutti hanno visto concretamente qual è stata la ripercussione ed è possibile anche stabilire una stima corretta dei costi che il problema ha causato (confrontando i guadagni attuali a quelli precedenti). Per questo la compagnia ha scelto di continuare a promuovere e mantenere attivi i processi di APM e ora sta pensando a estendere il monitoraggio delle transazioni dal distribuito fino al mainframe e alle call DB2 con Dynatrace APM4MF, aggiungendo semplicemente un agent z/OS. Il caso ci lascia un insegnamento importante: se siete alle prese con problemi di prestazioni, non passare il tempo a giocare a indovinare. Avviate le indagini. Potete partire semplicemente da un check dello stato di salute dei vostri siti web con uno strumento gratuito come il Performance Center Test di Dynatrace. Una volta raccolte le prime prove, verificando che una delle vostre pagine ha un malfunzionamento, chiamate un investigatore più esperto in grado di scavare a fondo con strumenti quali Dynatrace Application Monitoring.
