Application Performance Management

Indice

1. Introduzione all’APM - Application Performance

2. Scenario tipico di produzione

3. Le architetture

4. Gli attori coinvolti

5. Sistemi distribuiti

6. Definizioni

Introduzione all’APM - Application Performance

Questo articolo introduce i concetti ed i termini fondamentali dell’ Application

Performance Management (APM), utilizzando come scenario di esempio un
ambiente tipico per le applicazioni on-line basate sull'edizione enterprise di Java
(JEE).

L'obiettivo dell'APM è la gestione delle performance applicative, intese come

l'insieme dei requisiti (impliciti ed espliciti) non funzionali che caratterizzano la
qualità del servizio come percepita dall'utente. Per valutare la qualità del sistema
preposto all'erogazione del servizio, cioè quanto bene esso assolva lo scopo per cui
è stato costruito, si utilizzano degli indicatori quali tempi di risposta, disponibilità,
capacità etc etc. L’articolo presenta le metriche più utilizzate per monitorare la
qualità del servizio e ne esemplifica l'uso. L'utilizzo di metriche comporta la
disponibilità di misure, valori limite, andamenti storici e trend dei dati; essi
presentano in modo quantitativo ed oggettivo il quadro completo delle performance
applicative.

Queste misure sono prese nell'ambiente di produzione dove è necessario

considerare aspetti quali la sicurezza e l'impatto del monitoraggio sulle
performance applicative (overhead). In genere per l'overhead sono ammessi solo
pochi punti percentuali della capacità totale delle CPU di produzione, tipicamente il
2 o il 3%. In pratica più misure si prendono e maggiore è l'impegno di CPU
necessario. Per mantenere accettabile l'overhead è necessario l'uso di una
tecnologia evoluta e di configurazioni specifiche che limitano il numero delle
metriche a quelle strettamente necessarie. E' fondamentale quindi trovar l'equilibrio
tra queste due necessità contrapposte: da una parte quella di avere la massima
copertura del monitoraggio, dall'altra quella di avere il minimo overhead.

Per ottenere questo è necessario conoscere quanto più dettagliatamente possibile

l'architettura e gli utenti del sistema.
L’articolo descrive l'architettura tipica, o meglio quella consigliata dalle best
practice della JEE, sia dal punto di vista sistemistico che applicativo. Una chiara
comprensione dell'architettura è infatti uno dei prerequisiti per la corretta
applicazione delle tecniche dell'APM.

L'insieme dei profili delle persone coinvolte nella gestione e sviluppo del sistema
on-line, assieme alla sua complessità interna, fa intendere come il sistema sia da
trattare utilizzando gli strumenti tipici dei sistemi complessi. Vedremo infatti come il
monitoraggio separato secondo i diversi layer o ambienti (web, middleware, EIS,
rete) sia destinato a fallire per i sistemi distribuiti.

Scenario tipico di produzione

Diagramma 1: Scenario tipico di produzione

Come esemplificato dal diagramma 1, lo scenario tipico della produzione di

una applicazione web distribuita presenta una intrinseca complessità dovuta,
in primo luogo, ai diversi layer presenti. Solitamente lo specialista APM è
chiamato ad operare o per attività di troubleshooting oppure all'interno di un
progetto di monitoraggio. In entrambi i casi o il sistema è già operativo o
comunque in una fase finale di implementazione perciò è molto importante
riuscire a riconoscere i pattern architetturali più comuni e separare le
soluzioni custom da analizzzare di volta in volta.

L'utilizzo di standard rende possibile la scomposizione delle scenario

completo in sotto moduli interdipendenti. Inoltre rende superfluo la
descrizione dettaglia delle singole implementazioni dei diversi vendor e
permette così di focalizzare l'attenzione sul layer di interesse (applicativo,
infrastrutturale, sistemistico..etc.).

I diversi attori interagiscono con il sistema ognuno tramite una interfaccia

utente che maschera questa complessità, mostrando loro solo la parte di
proprio interesse e non tutti i moduli, che però utilizza e di cui necessita nelle
sue funzioni.

Diagramma 2: Scenario tipico di produzione con più dettaglio

Come si può dedurre dal diagramma 2, è inutile cercare di mostrare il

dettaglio mantenendo la visione di insieme. Meglio utilizzare la modularità
della soluzione e descrivere sistematicamente ogni singolo modulo,
fermandosi alle interfacce con gli altri moduli o con gli altri layer.

Esistono quindi diversi strati (i 'layers'), differenti fornitori dei prodotti (i

'vendors') e differenti profili delle persone che interagiscono e utilizzano
l'applicazione (i 'profiles').

Il risultato è un agglomerato potenzialmente complesso da controllare ma in

definitiva composto da parti che sono semplici da affrontare, a patto di
conoscere per ognuna di esse cosa sta facendo e perché è presente nel
sistema.
 Le architetture

L'architettura dell'applicazione deve essere affrontata dal punto di vista

applicativo e da quello sistemistico. Entrambi seguono le direttive e le
implementazioni dello standard J2EE, che prevede per l'AS un ruolo centrale
server side.

L’architettura applicativa

Figura 1: esempio di architettura applicativa

L'applicazione presenta una architettura interna basata su componenti

standard, ognuno con specifici compiti e funzionalità (Servlet, JSP, EJB,
connettori).

I componenti possono essere sviluppati in modo indipendente ed essere

deployati direttamente sull'AS; oppure tramite uno specifico framework
applicativo (Struts, Spring, Seam.. ). Poiché l'AS J2EE utilizza la JVM Standard
Edition (SE), le applicazioni JEE possono usare anche i Plain Old Java Objects
(POJO).

L’architettura sistemistica

Figura 2: esempio di architettura sistemistica

L'architettura distribuita prevede un Hub server side che riceve e smista le

richieste applicative (l'AS). Utilizza i dati e le funzioni dei sistemi di backend.

A seconda del tipo di applicazione si possono avere orchestrazioni di funzioni

già presenti nei back end, o elaborazione nel middleware dei dati presi dai
back end, o un mix di entrambi.

L'architettura di produzione viene clonata in pre-produzione, e normalmente

coesistono ambienti di integrazione e quality assurance.
 Gli attori coinvolti

Ogni attore è una persona che agisce nel sistema secondo uno scopo
predeterminato dal suo profilo.

Ogni profilo (utente, responsabili di business, operatore sistemistico,

sviluppatore, architetto, tester, operatore Q/A) ha le proprie
necessità e desiderata. Spesso utilizza un linguaggio e strumenti
specialistici, entrambi validi unicamente per i propri fini. Questi linguaggi però
non sono adatti allo scambio di informazioni con gli altri profili e ciò può
essere un fattore limitante nella gestione complessiva del sistema sotto
esame.

Nell’APM si individuano sei attori:

1. Customer
2. LOB manager
3. Operator
4. Developer
5. Q/A tester
6. Management

Vediamoli nel dettaglio.

Il cliente (Customer) utilizza l'applicazione per i suoi scopi di business ed

eventualmente chiede assistenza (per esempio ad un operatore di help desk).

Il responsabile della linea di business (LOB manager) è interessato al livello

di servizio e alla soddisfazione del cliente.

I tecnici delle operations hanno il monitoraggio completo, nel caso di avvisi

conoscono per primi il problema (prima degli utenti), ne capiscono l'origine e
sanno chi contattare di caso in caso.

Lo sviluppatore (Developer) implementa le nuove funzionalità, elabora le

correzioni all'applicazione.

Il Q/A tester controlla e verifica le funzionalità sotto test. Riproduce gli errori
utilizzando i dati opportuni. Assicura il corretto funzionamento in produzione.

Il Management controlla i costi, verifica che gli accordi sul livello di servizio
(SLA) siano rispettati, si assicura che il sistema e le persone lavorino
efficacemente.
Solo alcuni attori sono direttamente coinvolti nelle attività di gestione delle
performance dell'applicazione:

• LOB manager: Comunica gil SLA, controlla la soddisfazione del cliente,

produce report per il business e i manger
• Operator: Controlla la produzione 24/7, si attiva in modo proattivo alla
ricezione degli avvisi per evitare l'impatto sulla produzione
• Developer: Coinvolto nella ricerca delle cause di problemi applicativi,
eventualmente fornisce le patch
• Q/A - Application support: Raccoglie i dati degli incident, effettua il
triage sui diversi problemi

Sistemi distribuiti

Per raggiungere questi obiettivi, il sistema di produzione deve essere

mantenuto sempre sotto controllo. Le performance di produzione si valutano
real-time confrontando i dati di monitoraggio con i valori delle soglie
prefissate.

Dalla teoria dei sistemi complessi si evince come, per tenere sotto controllo
un sistema complesso, non sia sufficiente monitorare e caratterizzare i singoli
sottomoduli a se stanti ma è necessario monitorare le modalità di
interazione che sussistono tra di essi.

Questo è in antitesi con l'approccio cartesiano sulla scomposizione di un

sistema nei componenti. In questo modo infatti si fallisce nell'identificazione
delle 'Emergenze'. Con 'Emergenza' si intende il principio per cui dalle mutue
interazioni delle diverse parti nascono delle caratteristiche del sistema che
non si ritrovano tra le caratteristiche di alcuna parte singola.
 Definizioni

Nella parte finale di questo articolo si propongono le definizioni e il glossario

per indicare i concetti chiave dell’APM.

Conoscere e condividere questa terminologia è fondamentale per la

corretta comprensione e applicazione dell’APM su un progetto web in
produzione.

I termini che approfondiremo sono:

• Performance
• Response time
• Load
• Throughput
• Path length
• Bottleneck
• Capacity
• Scalability

Performance

Definizioni:

• Capacità dell'applicazione di soddisfare le aspettative dell'utente.

• Da notare come sia una definizione relativa all'utente e non assoluta.
Quindi, in funzione del profilo ci saranno risposte differenti alla
domanda: “Cosa sono le performance?'
• Dal punto di vista pratico si definiscono delle grandezze misurabili e si
definiscono valori di soglia per determinare le aree di lavoro con la
qualità desiderata.
• La mancata definizione delle performance come entità oggettiva
permette di superare le limitazioni di un approccio allo sviluppo del
software dominato dalle performance, mentre la definizione di valori
soglia per alcune metriche permette di sviluppare modelli previsionali,
cioè prima del completamento dello sviluppo, che valutano le scelte
architetturali ed il loro possibile impatto sulle performance.

Response time

Definizioni:

• Il tempo trascorso tra l'evento di invio della singola richiesta (click

dell'utente) e la presentazione della risposta.
 • E' una misura ad alta criticità perché, più di tutte le altre, si pone come
diretto indicatore della reattività (responsiveness) dell'applicazione agli
eventi utente.
• É composto dal tempo di rete (nei due sensi di andata e ritorno), tempo
applicativo (tempo necessario all'applicazione per generare la risposta,
comprensivo di attraversamenti di code interne) e tempo di
visualizzazione.
• Statisticamente è espressa in termini di percentile.

Figura 3: rappresentazione del Response-Time:Tempo necessario per

ottenere una risposta dopo aver effettuato una richiesta da parte dell'utente

Load

Definizioni:

• E' la misura del numero di richieste in un dato intervallo temporale.

• E' indicativo della 'pressione' esercitata sul sito dalle richieste degli
utenti.
• E' un valore dato del problema della gestione delle performance, su cui
difficilmente si riesce a interagire poiché dipende principalmente dal
comportamento degli utenti.
Figura 4: Rappresentazione del Load: carico utente che il sistema è in grado
di gestire in un intervallo temporale

Throughput

Definizioni:

• E' definito come il numero di risposte date nell'unità di tempo a fronte

di un certo numero di richieste (carico)
• Può essere uguale o molto diverso al valore del carico a seconda della
capacità del sistema di rispondere velocemente alle richieste.
• Oltre il punto di saturazione all'aumentare del carico , il throughput
resta costante al valore massimo, per poi scendere.

Figura 5: Rappresentazione del Throughput: Numero di risposte che il

sistema è in grado di erogare in un intervallo temporale

Path length

Definizioni:

• Si definisce come il numero di azioni eseguite all'interno del sistema

per completare una richiesta.
• E' indicativo sia della complessità delle azioni sia del numero di risorse
da impegnare su server per gestire la richiesta che saranno liberate e
rese disponibili solo alla fine.
Figura 6: Rappresentazione del Path length: Passaggi necessari per eseguire
una richiesta

Bottleneck

Definizioni:

• Letteralmente 'collo di bottiglia', è il termine usato per indicare una

strozzatura che limita il flusso concorrente delle azioni che gestiscono
le richieste.
• Tipico problema presente negli ambienti multi-threaded come il server
di una applicazione web.
• La velocità complessiva è dominata dal componente più lento.
• Una volta evitato un collo di bottiglia se ne può presentare un altro,
precedentemente 'nascosto' da quello appena risolto.
 Figura 7: Rappresentazione del Bottleneck: Punti del sistema che generano
un rallentamento del servizio fornito

Capacity

Definizioni:

• La capacità di un sistema è la misura del carico che il sistema riesce a

gestire mantenendo i tempi di risposta entro limiti predeterminati.
• E' un termine più esteso del throughput, e solitamente è espresso in
termini di sessioni utente all'ora.

Scalability

Definizioni:

• La scalabilità indica la qualità intrinseca di un sistema di espandere.

L'espansione può avvenire attraverso l'utilizzo di nuove risorse
hardware o software.
• Si dice scalabile un sistema che accetta l'inserimento di nuove risorse
per aumentare la sua capacità operativa. Quanto più è scalabile tanto
più l'inserimento è semplice.

Figura 8: Rappresentazione della Scalabilità: Capacità del sistema di

accedere a risorse hardware e software per rispondere ad aumenti di carico
utenti