Se ti sei perso le puntate precedenti eccole:

La pagina delle transazioni web

Vediamo ora come il discorso teorico sulla profilazione si applica al caso concreto.

Questa è la schermata delle transazioni di un Glowroot installato su un’istanza di Web.UP di test, che da poco prima delle 16 alle 17.30 è stata sollecitata dai test di performance, ovvero da utenti simulati che effettuano determinati percorsi di navigazione automatici.

smeup pagina transazioni web

A sinistra vediamo le url chiamate dagli utenti. Focalizzandoci sulla url principale dell’applicazione (/WebUPPerf/protected/web/webup.jsf) osserviamo come il tempo di risposta medio totale nelle ultime 4 ore risulta 692.9 ms.

Nella tabella Breakdown viene mostrata la disaggregazione dei tempi secondo la profilazione effettuata da Gloowroot. Ad esempio la riga “jsf render” con tempo medio 560 ms riguarda il tempo medio dello strato JSF dell’applicazione, ovvero della libreria di visualizzazione grafica utilizzata in Web.UP (Java Server Faces). Il tempo medio delle chiamate fatte da Web.UP a webservice esterni (sostanzialmente a Sme.UP Provider) è registrato alla voce “http client request” ed è pari a 88.5 ms. Il tempo consumato dalle librerie di logging è visibile alla voce “logging” ed è pari a 1.9 ms.

Il grafico mostra con chiarezza il peso dei tempi di esecuzione associando a ciascuna disaggregazione un colore.

Ad un primo esame quindi il maggior tempo impiegato dall’applicazione è nel rendering JSF, mentre il logging ad esempio non incide significativamente.

La schermata transazioni di Glowroot è quindi già un buon punto di partenza per individuare dove conviene intervenire ad ottimizzare le performance (nell’esempio in questione è indicato intervenire sullo strato di rendering JSF).

Sempre in tale schermata si ha la possibilità di notare la voce associata ad una instrumentation custom. La riga SmeupProviderCallInvoke appare perchè abbiamo instrumentato in Glowroot il metodo invoke della classe di Web.UP SmeupProviderCall.

Questa è la semplicissima schermata di configurazione della instrumentation (di cui ho parlato nel precedente articolo).

smeup pagina configurazioni instrumentation

Si può comprendere quanto potente sia lo strumento in questione. Invece di scrivere a mano all’interno del codice istruzioni di monitoring (ovvero scrivere ad esempio nel metodo invoke della classe SmeupProviderCall istruzioni simili a quelle del paragrafo sulla profilazione), rigenerare il pacchetto dell’applicazione e ripubblicarlo sul server, basta compilare una semplice pagina sull’APM. Oltre ad essere il processo più veloce il codice non è intaccato e complicato da istruzioni di monitoring.

Per completezza si allega la schermata del Glowroot installato sullo Sme.UP Provider verso cui il Web.UP dell’esempio precedente effettua le chiamate. Si nota in questo caso che la maggior parte (ma non la totalità) del tempo è spesa nelle chiamate all’As400 (As400NetServer è un’altra instrumentazione custom).

smeup pagina transazioni web2

Chiara Zambelli
Responsabile CI/CD – smeup
My LinkedIn Profile

Naviga per categoria:

Seleziona una categoria d’interesse dal nostro magazine