Performance Test Laboratorio di ingegneria del software Fabio Rabini
Cuncurrent Load & Active Users Libreria Libreria online Concurrent Load (o Users): Tutti gli utenti presenti in un dato istante nella libreria (11) Active Users: Tutti gli utenti che stanno richiedendo un servizio (6) Concurrent Load (o Users): Tutti gli utenti presenti in un dato istante sul sito (11) Active Users: Tutti gli utenti che stanno richiedendo un servizio (6) 2
Peak Load Peak Load: il numero massimo di utenti concorrenti nel periodo di riferimento (nell esempio della libreria il peakload è di 50 utenti dalle 16 alle 17) 3
Throughput Throughput: il numero di utenti serviti rispetto all unità di tempo Throughput Curve: mostra come varia il throughput rispetto al variare del Cuncurrent Load 4
Web Throughput Curve All umentare del carico la la pendenza diminuisce fino ad arrivare ad un upperbound ( punto di saturazione. ) Si raggiunge un bottleneck (collo di bottiglia) su qualche risorsa (es. CPU=100% di utilizzo). E equivalente al numero massimo di commessi nella libreria. All aumentare del carico il throughput rimane costante (il response time aumenta) Nella zona di carico leggero le richieste non sperimentano attese nell ottenimento di risorse (cpu, memoria,..). La crescita è lineare Throughput Curve: mostra come varia il throughput rispetto al Cuncurrent Load Qualche risorsa arriva al limite di gestione delle richieste. (es: newtork adapter). Il throughput diminuisce 5
Response Time Libreria Libreria online Response Time: Il tempo di attesa in coda + il tempo di servizio Response Time: è il tempo che va da quando un utente attiva una richiesta a quando riceve la risposta 6
Throughput vs Response Time Graph Throughput (Kb/sec) Response Time (sec) Light Load Saturation Point Heavy Load Throughput Falling Buckle Zone Fino al raggiungimento del punto di saturazione del throughput il tempo di risposta è costante Dopo la buckle zone la crescita del tempo di risposta non è lineare Dopo il raggiungimento del punto di saturazione del throughput la crescita del tempo di risposta è lineare Load 7
Response Time Graph 8
ThinkingTime Thinking Time: è il tempo che intercorre tra una risposta e la richiesta successiva. E utilizzato dall utente per leggere,interpretare il risultato di una risposta (ed altro break, pranzo, ) 9
Optimization (o Tuning) Ottimizzazione Eliminare codice inutile Eliminare memory leak Identificazione e rimozione dei bottleneck (attesa di risorse indisponibili perchè occupate a servire altre richieste). Ottimizzazione degli algoritmi (ottimizzare la complessità computazionale) Performance Tuning del codice. Ad esempio in java Tuning Java (es: Usare StringBuffer invece di String per la manipolazione di stringhe) Tuning Servlet (es: evitare il single thread model, evitare System.out.println,...) Tuning EJB (es usare Local Interfaces invece di Remote Interface) Performance Tuning delle piattaforme (JVM, Application Server, Web Server, Database, ) Scalare (aggiungere risorse per aumentare le performance) Verticale Aumento delle risorse di calcolo e di memoria su un singolo server Orizzontale Clustering 10
Clustering Esegue il dispatch delle richieste su server A e su server B secondo politiche definite (es:50%/50%). Il clustering completo (tutte le risorse ridondate) consente una crescita lineare del throughput. Se Server A = Server B, il throughput massimo sperimentato nel punto indicato dalla freccia equivale = 2* throughput del Server A) 11
Una architettura classica per web application Alcuni elementi chiave - Timeout - Processi e Thread (Listeners) Alcuni elementi chiave - Istance Pooling - Caching - Indici - Politiche di allocazione e riorganizzazione dei dati 12
Una topologia classica per web application 13
Performance Tool Performance Test Registration&Playback Load Generation Data Monitoring & Collection Tool CPU Network Memoria JVM Heap Application Profiling Es: JProfile 14
Performance Test Tool script I tool di performance test registrano il comportamento reale dell utente frapponendosi tra il client ed il sito web e creano così una prima versione dello script che eseguito simulerà un singolo utente (Virtual User). Successivamente sarà possibile simulare più utenti concorrenti eseguendo Simultaneamente più Virtual User 15
Performance Test Tool Tre Moduli: VU Generator Controller (Monitor) Analysis 16
Performance Test Tool (Master/Slave) Esecuzione degli script (Virtual User) ed invio dei dati Orchestrazione degli script (Virtual User) e raccolta dei dati 17
Test Environment 18
Tool di Monitoring Application Specific metrics Profile (es: JProfiler) System-related metrics Windows System Monitor (CPU, Network, Memoria) Platform Specific metrics JVM Heap Monitor (Heap allocation) 19
Una metodologia di Performance Test Precondizioni: Test funzionali superati Ambiente di test adeguato in relazione a quello di produzione Step: 1. Stabilire l obiettivo del test 2. Identificare la strategia di test 3. Identificare le metriche da rilevare e configurare gli strumenti per acquisire dati 4. Progettare e implementare il workload(*) da applicare 5. Eseguire il test e produrre report 6. Interpretare i report per identificare azioni di performance tuning 7. Eseguire azioni di performance tuning e ritornare al pto 5 fino a che i risultati non sono soddisfacenti Workload(*) = profilo di carico F(n utenti, transazioni effettuate, tempo di esecuzione del test) 20
1) Stabilire l obiettivo del test Identificare il massimo carico sostenibile Identificare la presenza di colli di bottiglia Identificare eventuali difetti legati all accesso concorrente di utenti (gestione errata della transazionalità,.) Verificare la stabilità complessiva dell applicazione rispetto ad un carico continuo e prolungato (es: presenza di memory leak) 21
2) Identificare la strategia di test Stress Test Workload Test (Ramp UP) >> Workload Esercizio Una sola funzionalità o sequenza limitata Goal: Valutare il comportamento in situazioni di picco, raggiungere il punto di rottura Load Test Workload Test (Ramp Up) Workload Esercizio Transazioni di Business Goal: Valutare il comportamento in situazioni di carico reale Stability Test Workload Test < Workload di Esercizio Transazioni di Business o singole funzionalità Goal: Evidenziare problemi di stabilità con un carico ridotto per un lungo periodo di utilizzo (24x7). E importante per evidenziare fenomeni di accumulo che portano a saturazione (con conseguente degrado delle performance e crash) di alcuni tipi di risorse (memoria, pool di connessioni, ecc.) 22
3) Metriche Network-specific metrics. Forniscono informazioni sull efficienza della rete, includono routers, switches e gateways. System-related metrics. Forniscono informazioni sull utilizzo delle risorse del server come processore, memoria, disk I/O, and network I/O. Platform-specific metrics. Forniscono informazioni sulla piattaforma su cui viene effettuato il deploy della applicazione (es: jvm, tomcat, glassfish, jboss) Application-specific metrics. Forniscono informazioni di performance relative alla applicazione (contatori e time-stamp custom inseriti nel codice, profiler probe ) Service-level metrics. Forniscono informazioni circa il throughput e la il response time complessivo Business metrics. Forniscono informazioni sulle performance a livello di business (es: il numero degli ordini in un dato timeframe) 23
3) Monitoring Tool (example) Application Specific metrics Profile (es: JProfiler) System-related metrics Windows System Monitor (CPU, Network, Memoria) Platform Specific metrics JVM Heap Monitor (Heap allocation) 24
4) Definizione del Workload Workload = Profilo di carico F(n utenti, transazioni effettuate, tempo di esecuzione del test) Come si progetta un (buon) Workload? A partire dai file di Log (Benchmarking) Attraverso Analisi congiunta con il cliente Attraverso Analogie con applicazioni simili Step 1: Identificare le transazioni Utilizzo elevato Indispensabilità della funzione Complessità dell eleborazione Numero di utenti concorrenti Numero di transazioni al giorno Esistenza di picchi di utilizzo 25
4) Definizione del Workload Step 2: Identificare i percorsi applicativi Percorso = insieme di transazioni di Business Es: sito di E-commerce 60 % path1: Navigazione sulla home page, funzionalità di search e browsing di 4/5 pagine generiche del sito 25 % path2: Navigazione della Home page e browsing del catalogo 10 % path3: Acquisto di un prodotto senza registrazione 5 % path 4: Registrazione e acquisto Quali Funzionalità/Transazioni utilizzereste nel caso di: Un Test di Stress? Un Test di Load? 26
4) Definizione del Workload Step 3: Stabilire il Numero Max di Utenti Concorrenti A partire dal numero di transazioni/ora (reali o ipotizzate) Concurrent User = 2 * [(NR)/T] N = numero di transazioni effettuate nell intera giornata di lavoro R = durata complessiva della transazione (include Think Time) T = numero giornaliero di secondi durante i quali l applicazione è eseguita Es: 2000 transazioni l ora, ognuna della durata complessiva di 15 secondi, T= 28.800 secondi Peak = Circa 30 utenti in parallelo contemporaneamente NB: Il think time, o meglio la sua distribuzione va modellata: ad esempio si può supporre che il Think Time sia distribuito come una gaussiana 27
4) Definizione del Workload Modellare la concorrenza delle sessioni (ossia stabilire la distribuzione degli utenti nel tempo) A Rampa Simultanei Steady State: carico concorrente costante (anche per lunghi periodi) Ramp-Up Ramp-Down 28
5) Interpretare I Risultati Esempio interpretazione dei risultati: Average Transaction Response Time Response time VS # users Light Load Heavy Load Buckle Zone 29
5) Interpretare I Risultati Esempio interpretazione dei risultati: Throghput Throughput VS # users Light Load Heavy Load Buckle Zone 30
5) Interpretare I Risultati Esempio interpretazione dei risultati: Distribuzione del Transaction Response Time 31
5) Interpretare I Risultati Esempio interpretazione dei risultati: Percentile del Transaction Response Time 32
5) Interpretare I Risultati Esempio interpretazione dei risultati: Time to first Buffer Breakdown 33
Business Case: Interpretare i Risultati Caso 1: una applicazione web in esercizio cade regolarmente approssimativamente ogni 7 giorni (ogni week end) 34
Business Case: Interpretare i Risultati Profiling dell applicazione tramite Jprofiler 35
Business Case: Interpretare i Risultati Andamento del profilo dell heap size dopo la correzione 36
Business Case: Interpretare i Risultati Nuovo comportamento: l applicazione adesso non cade più regolarmente il ma sistema si rende comunque indisponibile occasionalmente 37
Business Case: Interpretare i Risultati Errata impostazione della Configurazione. il web server (Apache), installato sul front-end, non esegue alcun filtro nei confronti delle richieste pervenute da parte degli utenti. 38
Time Evento Azione / Contromisura Ven 17/02/2006 Apertura Ticket Staffing Task Force Risoluzione del difetto Analisi dei file di Log in produzione Replica presso il CED di EnterpriseDA dell ambiente di produzione di Bari Predisposizione della baseline di Impatto e suo deploy in ambiente di test Monitoring della situazione in test per ricreare le condizioni dei errore Sab 18/02/2006 Ricreata la condizione di errore. Modifica delle impostazioni di gestione della memoria e bugfixing sul codice. Smoke test Inizio monitoring dell ambiente in produzione tramite probe JProfiler Lun 20/02/2006 Test di Regressione completo Analisi delle performance in ambiente di Test Analisi delle performance in ambiente di produzione Build della nuova versione patched Mar 21/02/2006 Test di regressione superati Ore 18.00: Deploy della versione pached in ambiente di produzione Mer 22/02/2006 Analisi delle prestazioni in produzione: rilevata una errata configurazione (vedere paragrafo: note a margine delle attività) Gio 23/02/2006 Chiusura Ticket 39
Business Case: Interpretare i Risultati Caso 2: In seguito ad un Test di Load l applicazione ha mostrato il seguente comportamento Andamento throughput vs Time 120 100 80 Kbytes 60 40 20 0 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 minuti (elapsed) Utenti (VUser) 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 Profilo di carico 1 2 3 4 5 6 7 8 9 10 11 12 13 Time (minuti elapsed) 40
Performance Test Execution: Common Tips Assicuratevi che l ambiente di test riproduca fedelmente l ambiente di esercizio (Risorse Hardware & Software) Monitorate le risorse del server (Ram e CPU) ma anche quelle del client!!! Evitate di sovraccaricare l applicazione con workload sproporzionati alla reale situazione di esercizio La rete non dovrebbe mai essere il collo di bottiglia del sistema (monitorate il network time) Ricordatevi di valutare il Think Time! No requisiti? No Test 41
Tool di Performance Test: JMeter Laboratorio di ingegneria del software Fabio Rabini
Apache JMeter Applicazione Java stand-alone utile per l'esecuzione di test di performance e per la misura delle metriche di performance (service-level) Originariamente progettato per testare applicazioni Web (http) è stato esteso per: FTP RDBMS (JDBC) etc. 43
JMeter: concetti di base (1/3) TestPlan: Descrive la serie di passi che JMeter eseguirà nell esecuzione dei test: è formato da uno o più ThreadGroups ThreadGroup: Rappresenta il punto di partenza di ogni Test Plan Modella il comportamento di un insieme di richieste simultanee (simula il comportamento di un certo numero di utenti concorrenti che fanno la medesima richiesta). Di fatto modella uno scenario di carico Thread Ogni Thread viene utilizzato per eseguire le azioni di un virtual user (di fatto Thread = VU) 44
JMeter: concetti di base (2/3) Timer: elemento che caratterizza il comportamento di un ThreadGroup Constant timer Gaussian random timer Uniform random timer Rappresenta di fatto il tempo che intercorre tra una richiesta di un thread e un altra (thinking time) Nota: senza un timer si simulerebbero degli iper-utenti 45
JMeter: concetti di base (3/3) Sampler Interagiscono con l applicazione testata. Esistono diversi Sampler per diversi protocolli (JDBC, HTTP, FTP, ecc.) Per le applicazioni web si può utilizzare il Sampler HTTP Request Simula l azione dell utente Logic controller Determina l ordine con cui i Sampler vengono eseguiti. Listener: L informazione prodotta dai Sampler è consumata dai Listener Esistono listener per rappresentare i risultati in modo diverso: Graph, TreeView,... 46
JMeter: ciclo di vita di un TestPlan Definizione del TestPlan Avvio del Test: JMeter compila gli elementi di test; Viene istanziato un oggetto TestPlan; Viene configurato il JMeterEngine; Vengono avviati i vari threads. Stampa dei risultati del test: grafici xml... 47
Un esempio di utilizzo Obiettivo: testare una Web application. Strategia: settare un ThreadGroup aggiungere dei HTTP request sampler al ThreadGroup settare un timer settare alcuni listener 48
1: avvio di JMeter WorkBench TestPlan Area di lavoro utile per costruire e configurare tests. Contiene TestPlan attivi e pronti per essere eseguiti 49
2: aggiungere un Thread group 50
3: configurare un Thread group 51
4: aggiungere un sampler 52
5: aggiungere un timer 53
6: aggiungere un listener 54
7: aggiungere altri listener View result tree (il listener appena inserito). Utile in fase di creazione del test plan per verificare le risposte del server. Graph results e Splin visualizer. Mostrano i risultati della simulazione sotto forma di grafici. Simple data writer. Memorizza i dati della simulazione su un file XML 55
Dove eseguire JMeter? Sulla stessa macchina che esegue il server web? pro: non ci sono ritardi introdotti dalla rete contro: Jmeter entra in competizione per le risorse del server. Su una macchina remota? pro: Jmeter non influisce sulle prestazioni del server contro: possibili ritardi introdotti dal traffico del segmento di rete utilizzato Su più macchine remote? pro: si minimizza il problema dei colli di bottiglia di rete contro: configurazione e avvio un po' più laborioso 56
Dove eseguire JMeter? Fate sempre questi Check prima di iniziare! I firewall sulla rete devono essere spenti Tutti i client devono essere sulla stessa subnet Il server (target) deve stare sulla stessa subnet (se utilizza IP che cominciano con 10 o 192) Verificare che Jmeter acceda al target E buona norma che le versioni di Jmeter sui vari sistemi siano le stesse 57
Questions? 58
Thank You for Your Attention! 59
Bibliografia Performance Analysis for Java(TM) Websites Stacy Joines, Ruth Willenborg, Ken Hygh JMeter User Manual http://jakarta.apache.org/jmeter/ http://jakarta.apache.org/jmeter/usermanual/jm eter_distributed_testing_step_by_step.pdf 60