Stress test e performance di un WebService

Avete realizzato il vostro WebService utilizzando la tecnologia XYZ, però ora volete verificare come si comporterà il vostro servizio sotto stress? Vediamo come analizzare questa situazione utilizzando JMeter e VisualVM

Stress test con JMeter

JMeter è un prodotto opensource che ci permette di testare la nostra applicazione, simulando una serie di circostanze. Può essere utilizzato per connessioni HTTP, JMS, JDBC, WebService etc. etc. e in ogni caso di test possiamo configurare una serie di parametri che possono essere utili nel momento in cui vogliamo testare uno specifico scenario della nostra applicazione.

L’installazione è abbastanza semplice, perchè basta scaricarlo dal sito di Apache e decomprimere il file sul nostro computer. JMeter permette di inserire dei plugin, che possono essere molto utili perchè definiscono un caso di test specifico per una particolare tecnologia o anche listener grafici che ci permettono di visualizzare al meglio le informazioni relativo al nostro caso di test.

Installiamo quindi i JMeter Plugins, una serie di componenti che potrebbero tornarci utili anche in molte altre occasioni, scaricando da https://code.google.com/p/jmeter-plugins/. Per installare questo pacchetto aggiuntivo dobbiamo semplicemente copiarlo nella cartella $JMETER_HOME/lib/ext e la versione del nostro JMeter deve essere superiore alla 2.8

 

Test Plan

La prima da cosa configurare per il nostro test è quanti thread devono essere lanciati e in che modo. Per fare ciò basta cliccare col tasto destro su Test Plan e aggiungere un jp@gc – Stepping Thread Group

La configurazione standard prevede di avviare 100 thread, a gruppi di 10 e successivamente fermarli 5 alla volta. Per fare un test più veloce abbassiamo in questo caso il numero a 40 e come potete vedere dalla seguente immagine JMeter ci permette di vedere l’andamento che avrà il test in base ai thread che verranno lanciati

Ora dobbiamo specificare che tipo di test stiamo facendo, specificando il Content-Type delle nostre chiamate HTTP e soprattutto inserendo il payload della chiamata SOAP che vogliamo testare. Quindi sul thread group che abbiamo inserito precedentemente aggiungiamo un HTTP Header Manager

Add > Config Element > HTTP Header Manager

e come coppia nome-valore inseriamo Content-Type e text/xml. In questo modo abbiamo specificato il Content Type gestito durante il test. Ora passiamo alla vera e propria chiamata SOAP aggiungendo un Sampler. Questo è il componente che ci permette di effettuare una richiesta e potete vedere che JMeter ci permette di configurare molti Sampler, ad esempio per JMS, JDBC, REST, SMTP.

Quello che ci serve in questo caso è una semplice richiesta HTTP con il payload SOAP che andremo ad inserire. Quindi aggiungiamo al thread group un HTTP Request

Add > Sampler > HTTP Request

quindi inseriamo l’URL del nostro WebService, specifichiamo Implementation HTTPClient4 e inseriamo la richiesta SOAP in Post Body.

A questo punto dovremmo configurare qualcosa per avere dei dati riguardanti il nostro test. JMeter mette a disposizione molte opzioni per estrapolare informazioni dai test e in questo caso, essendo un test con solo 30 richieste HTTP, utilizzeremo una tabella che ci mostra l’andamento delle risposte in base al tempo. Per aggiungerla tasto destro sempre sul thread group

Add > Listener > jp@gc – Response Times Over Time

E’ da tenere a mente che quando stiamo effettuando dei test più pesanti, elementi come questo che abbiamo appena aggiunto portano spesso JMeter ad un OutOfMemory, in quanto si tratta di componenti grafici che tengono traccia di tutti i thread che sono in esecuzione. Ora possiamo mandare in esecuzione il test e una volta che è terminato (ridiventa disponibile il tasto start) possiamo vedere i risultati dal listener che abbiamo aggiunto

La nostra applicazione ha sempre risposto correttamente alle richieste che sono state effettuate, variando il tempo di risposta. Il WebService che stiamo testando in questo caso non è un semplice Hello World ma qualcosa di più complicato, infatti come potete vedere i tempi di risposta di allungano quando ci sono più richieste simultanee. E questo già ci permette di gioire del fatto che riusciamo a gestire qualche richiesta in concorrenza senza far scoppiare niente 🙂

 

VisualVM

Per indagare meglio su come si sta comportando il nostro WebService durante lo stress test, possiamo utilizzare il tool che ci viene fornito insiema alla JDK, VisualVM. Facciamo partire questo tool sulla macchina dove sta girando il nostro WebService. Il tool è presente nella cartella bin della vostra JDK quindi se avete questa cartella nel vostro PATH vi basta scrivere jvisualvm da una console dei comandi.

Avviata l’applicazione selezioniamo l’applicazione JBoss dove è stato lanciato il WebService in questione e vediamo l’attuale situazione della memoria

Dopo aver eseguito il test il grafico della memoria è cambiato in questo modo

A questo punto possiamo crea un dump del Heap per andare a vedere se ci sono problemi evidenti che si possono riscontrare ad una prima analisi. VisualVM e in generale l’analisi delle performance di un applicazione è un tema abbastanza variegato, per cui lo approfondiremo successivamente in un articolo. Per il momento, come indicazioni di massima, basta tenere a mente che

• Il numero di classi caricate che aumentano potrebbe indicare un problema nel class loading, che potrebbe sfociare in un OutOfMemoryError
• Se aumenta sempre il numero dei thread potrebbero esserci dei metodi asincroni che vanno a rilento
• In generale un aumento della memoria consumata può ovviamente portare ad un OutOfMemoryError

 

Riferimenti e approfondimenti

 Apache JMeter – Building a Web Test Plan

JMeter Performance and Tuning Tips

Java Profiling with VisualVM

Fix Memory Leaks in Java Production Applications