Académique Documents
Professionnel Documents
Culture Documents
L’applicazione oggetto del test è stata realizzata in Grails 1.3.6, per il database è stato utilizzato
MySQLServer 5.0. Il DB consta di tre tabelle (utente, proprietario, auto), ma in fase di test ne sono
state utilizzate solo due (Utente per la login, proprietario per l’aggiunta di un nuovo record e per la
lista).
Il deploy dell’applicazione è stato fatto su Apache Tomcat 6.0 residente su una workstation
Window XP, la stessa su cui è presente il DB.
I test sono stati effettuati da PC remoti utilizzando una LAN isolata, per evitare che i risultati
potessero essere falsati da un sovraccarico del traffico di rete.
Per il monitoraggio del comportamento dell’applicazione è stato utilizzato JMeter 2.4
JMeter è tool opensource sviluppato dalla Apache Software Foundation che permette di effettuare
test di carico di qualsiasi tipologia di software, comprese le Web Applications. È possibile simulare
la concorrenza attraverso i Threads permettendo quindi di misurare la performance al variare del
carico attraverso la generazione di valori statistici come la media, la mediana, la varianza e il
throughput.
Prima di tutto bisogna creare un Test Plan che descrive gli step da seguire per l'esecuzione del
Test. È possibile configurare i seguenti parametri:
Name: ciascun piano di test viene identificato con un nome
User Definned Variables: è possibile associare al piano di test n variabili che possono
essere richiamate all'interno del test;
Run Thread Group consecutively: è possibile stabilire se i thread (utenti virtuali) devono
essere avviati in modalità sequenziale (al termine di un thread viene avviato il successivo)
oppure in modalità parallela (viene lanciato il primo, dopo k secondi viene lanciato il
secondo, dopo 2k secondi il terzo e così via);
Library: è possibile aggiungere delle classi o dei pacchetti jar al classpath.
Nei test effettuati si è provveduto solamente a specificare il Name, che comparirà nel menù ad
albero sulla sinistra, lasciando invariate le altre opzioni.
Cliccando con il tasto destro del mouse sul nome del nostro Test Plan possiamo iniziare ad
aggiungere un Thread Group, l’elemento che conterrà tutti gli altri. Una volta specificato il nome si
va a configurare le seguenti proprietà:
Una volta aggiunto un Gruppo di Thread, con una procedura analoga, possiamo impostare un
Config Element di tipo HTTPRequestDefault.
Dopo aver specificato il nome dell’ HTTPRequestDefault andremo ad inserire i parametri di
connessione del server su cui gira l’applicazione da testare, cioè l’indirizzo e la porta
A questo punto possiamo aggiungere le HTTPRequest che ci interessano, sempre con il solito
sistema, tasto destro sul Thread Group Add->Sampler->Http Request.
Per ogni step del flusso è stata creata un HTTPRequest, in modo tale da monitorare ogni
passaggio.
L’ultima operazione da effettuare è la scelta dei Listener, che ci permetteranno di leggere i risultati
del test secondo parametri e visualizzazioni diverse. Nel nostro caso abbiamo utilizzato i seguenti:
- View Result Tree che riassume tutte le richieste e risposte HTTP eseguite durante il test. Per ogni
Thread viene visualizzato l’esito della richiesta con relativa descrizione dettagliata.
- View Result in Table, in cui l’esito delle richieste di ogni Thread è visualizzato in tabella con
minor dettaglio di informazioni.
- Graph Result, che permette di visualizzare il grafico dell’intero test per quanto riguarda
Throughput, Media, Mediana e Deviazione Standard
- Aggregate Graph, che riassume i dati totali e per singola HTTPRequest in una tabella, dando
anche la possibilità di costruire grafici per valutare i tempi di risposta.
Una volta configurati i Listener possiamo far partire il test dalla voce di menu Run -> Start, o
alternativamente la combinazione di tasti CTRL+R. Per arrestare il test Run -> Stop o
alternativamente la combinazione di tasti CTRL+. .
Figura 1 - Curva che rappresenta il throughput al variare delle utenze con un Ramp-up a un secondo.
Figura 2 - Curva che rappresenta la durata media di ogni ciclo del thread.
Anche qui si è notato che il throughput KB/sec rimane costante per tutti i test effettuati a un
valore medio di circa 275-280 KB/sec.
Nel terzo test effettuato abbiamo portato il valore di Ramp-up a 5 secondi.
Il throughput da 1 a 5 utenze scende molto, mentre da 5 a 50 utenze si ha un nuovo aumento di
valore fino a assumere un andamento che si può definire costante fra le 50 e le 200 utenze. Il
tempo di esecuzione del thread medio rimane costante in relazione ai due test di prima, da 1 a 10
utenze si ha un tempo di esecuzione costante valorizzato a circa 33 ms, mentre da 50 a 200 utenze
si ha un incremento proporzionato. In questo caso l’eccezione viene lanciata oltre le 200 utenze.
Dopo aver effettuato diversi test si è constatato che sulle prestazioni dell’applicazione non incide
tanto il traffico di rete, quanto la mole di dati presente sul DB. A tal proposito non abbiamo
riscontrato rilevanti differenze tra i risultati dei test effettuati su LAN aperta e quelli effettuati su
LAN isolata. Al contrario abbiamo assistito ad un calo delle performance man mano che si riempiva
il DB: già con tabelle di 1000 record il throughput medio subiva un incremento del 5%. Vista
l’incidenza del riempimento delle tabelle sulle prestazioni dell’applicazione, si è provveduto a
svuotare il DB ogniqualvolta ci si avvicinava ai 5000 record scritti.