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.
In sede di test potrebbe essere conveniente utilizzare dei parametri random in vece di settarli a
mano; in questo caso bisognerebbe utilizzare una funzione esterna che generi una stringa casuale.
Per implementare questa funzionalità abbiamo sviluppato il seguente metodo:
String generateRandomString(int n) {
char[] pw = new char[n];
int c = 'A';
int r1 = 0;
for (int i=0; i < n; i++) {
r1 = (int)(Math.random() * 3);
switch(r1) {
case 0: c = '0' + (int)(Math.random() * 10); break;
case 1: c = 'a' + (int)(Math.random() * 26); break;
case 2: c = 'A' + (int)(Math.random() * 26); break;
}
pw[i] = (char)c;
}
return new String(pw);
}
Per poter sfruttare questo metodo bisogna andare a modificare il file BeanShellFunction.bshrc
all'interno di jakarta-jmeter->bin, inserendo la funzione da eseguire nel test plan. Il passo
successivo è andare a modificare il file jmeter.properties all'interno di jakarta-jmeter->bin
abilitando il comando #beanshell.function.init=BeanShellFunction.bshrc (togliendo il carattere #
che indica il commento). Ultima cosa da fare è impostare il “Value” nelle singole Http Request a
${__BeanShell(nomefunzione(param))}, dove "nomefunzione" è il nome della funzione definita in
jakarta-jmeter->bin, e "param" è la lista di parametri che la funzione vuole in ingresso.
Appendice 2 – Generazione automatica delle risorse da monitorare
A proposito del monitoraggio delle risorse abbiamo detto che bisogna configurare singolarmente il
path delle HTTPRequest. Se volessimo configurare automaticamente questi path, completando un
ciclo di operazioni con la semplice navigazione dell’applicazione da monitorare, è necessario
configurare un server proxy, strumento che JMeter mette a disposizione.
Andiamo a creare un Recording Controller e un HTTP Proxy Server in questo modo:
tasto destro sul ThreadGroup Add -> Logic Controller -> Recording Controller;
tasto destro sul Workbench Add -> Non-Test Elements -> HTTP Proxy Server.
In assenza di particolari necessità lasciare invariati i settaggi di entrambi.
Per completare la procedura andiamo a modificare manualmente i parametri del proxy all’interno
del browser che utilizziamo, settando l’indirizzo e la porta.
A questo punto possiamo andare sulla finestra dell’ -> HTTP Proxy Server di JMeter e dare il
comando di start al nostro proxy. Apriamo il browser e iniziamo a navigare all’interno della nostra
operazione: ci accorgeremo che per ogni nostra azione verrà generata una o più HTTPRequest, a
seconda delle risorse richiamate. Una volta terminato il ciclo di operazioni che ci interessa testare,
non ci resta che scegliere quale HTTPRequest mantenere all’interno del nostro ThreadGroup, in
modo tale che quando faremo partire JMeter potremo monitorare solo gli step selezionati.