Guida di JMeterCOS'È JMETER:

JMeter è un'applicazione desktop sviluppata dalla Apache Software Foundation che permette di effettuare test di carico delle proprie applicazioni. Questo strumento è totalmente Open Source e consente di registrare ed eseguire scenari di performance o di stress in modo molto semplice.

La versione presa in considerazione in questa mini guida è la 2.3.4.

PUNTI DI FORZA E DEBOLEZZA

Pro: Jmeter pur essendo un tool open source, possiede una documentazione ben curata, che ci

permette di avere un valido supporto; Grazie all’interfaccia grafica, ed alla guida online, consente di avere una curva di

apprendimento molto alta; E’ possibile testare la maggior parte delle applicazioni web, ed anche applicazione non web-

based come ad esempio: database o mail; Possiede un tool interno che ci permette di registrare la navigazione web effettuata tramite

un browser, per rendere più semplice la costruzione dello script di test.

Contro: Non è possibile registrare le pagine che si basano sul protocollo (HTTPS), infatti l’unico

modo per bypassare questa limitazione è ad esempio utilizzare un altro tool chiamato Badboy;

L’interfaccia grafica, tende a diventare un po’ tediosa, nel momento in cui la si vuole utilizzare in modo avanzato;

Tende a diventare instabile quando si eseguono un gran numero di test.

Elementi base di JMeter (JM)

Prima di cominciare ad elencare gli elementi più importanti per scrivere un piano di test con JM bisogna specificare che JM si basa su di una logica ad albero, infatti tutti gli elementi saranno figli del Test Plan, ed a loro volta gli elementi figli potranno avere:

Altri figli Fratelli: i quali possono stare in cima o sotto di loro.

Questa differenza è dovuta al fatto che oltre a rispettare una gerarchia padre/figlio, JM nel caso di fratelli esegue sequenzialmente le chiamate.Infine vi sono elementi che hanno un peso o priorità maggiore, perciò possono essere richiamati prima di un elemento che in logica gerarchica li precede.

>Piano di Test (Test Plan):

Il Test Plan contiene le informazioni generali sui test come, oltre ad essere il primo aggregatore di elementi del test stesso. Può essere definito come il nodo radice che contiene uno o più Thread Groups.

>Thread Group (TG):

Un thread group (TG) definisce un insieme di utenti virtuali (VU) che dovranno essere eseguiti all’interno di un piano di test. Questo elemento è la colonna portante di Jmeter poiché conterrà quasi tutti i restanti elementi di JM.

Impostazioni:

Action to be taken after a Sample error: permette di scegliere quali azioni intraprendere nel caso durante l’esecuzione dei test si venisse a verificare un errore

o Continue: Continua;o Stop Thread: ferma soltanto il singolo thread (ovvero il singolo VU);o Stop Test: ferma l’intero test.

Thread Propertieso Number of threads (user): indica il numero di utenti virtuali (VU) che si desidera

generare all’interno del TG.o Ramp-Up Period (in second): indica il tempo complessivo che JM dovrà impiegare

per lanciare tutti i VU sceltio Loop Count: E’ possibile definire il numero di volte che il TG sarà eseguito, nel

caso in cui volessimo che il test si eseguisse all’infinito, basta selezionare il flag “forever”.

Scheduler: E’ possibile schedulare l’inizio e la fine dei test.

Perciò per i nostri bisogni dobbiamo scegliere il Periodo di Carico vale a dire il tempo che deve trascorrere tra l’entrata di un utente ed il suo successivo.

Periodo di Carico = RampUp / Totale dei VUs

Perciò se ho 30 VU e voglio che ogni utente aspetti 10 secondi prima di entrare all’interno del sito, dovrò impostare un RampUp di 300s

Config Element (Elementi di configurazione)

Gli elementi di configurazione possono essere utilizzati per definire costruzioni di default e variabili che dovranno essere utilizzati da altri elementi. Nota: Questi elementi verranno saranno processati alla partenza nell’ordine in cui si trovano.

>Http Request Default:

Questo elemento permette di settare i valori di default che l’http request controller dovrà utilizzare, in questo modo nel caso vi siano delle modifiche all’indirizzo o alla porta del nostro web server, non saremmo costretti a replicare la modifica in ogni singolo elemento.

Web Server:o Server Name or IP: E’ possibile definire il server o inserire l’ip del server da

testare;o Port Number: E’ possibile definire la porta con cui deve comunicare.

Http Requesto Protocol: http o https.

>Http Cookie Manager:

L’http Cookie Manager ha due funzioni:1. Si occupa di salvare i cookie che vengono generati della richiesta al server, e di riutilizzarli

nelle future chiamate al server stesso. Ogni Thread possiederà il suo specifico cookie, in questo modo ogni singola richiesta potrà simulare una session indipendente.

2. E’ possibile aggiungere manualmente al cookie manger un proprio cookie, ma questo verrà condiviso tra tutti i thread.

Opzioni del Cookie Manager:

Clear cookie each iteration: permette di cancellare dalla memoria i cookie ogni volta che il Thread Group esegue un nuovo loop.

Cookie Policy: compatibility e consigliato.

>User Defined Variables (Variabili definite dall’utente):

Questo elemento permette di definire delle variabile che potranno essere utilizzate da altri elementi di JM. Le variabili definite all’interno hanno precedenza anche sulle variabili definite nel Test Plan, perciò le variabili create qui dentro possono essere viste come variabili globali all’interno dell’applicazione, infatti, se all’interno di un sotto elemento venisse definita tramite un altro elemento di JM una variabile con lo stesso nome, questa avrebbe visibilità locale e non influirebbe sulla visibilità della variabile globale.

Per poter richiamare le variabili è necessario scrivere ${nome variabile}, ad esempio: ${name} restituirà il valore “cesare”.

>CSV Data Set Config:

CSV Data Set Config è utilizzato per leggere linee da un file, e dividerle in variabili.

Caso Reale: durante la realizzazione dei test, soprattutto di tipo performance e stress si ha la necessità si eseguire più chiamate al server con parametri diversi per ogni singolo Thread. Costruendo un file csv, si ha la possibilità di gestire il numero e la tipologia di chiamate che saranno effettuate.

Es: Posso costruire un file csv contenente tutti i login e password del mio portale, in modo da testare la login al portale stesso di tutti gli utenti.

Es. di file CSV:

user1;password1;id1user2;password2;id2user3;password3;id3

Configure the CSV Data Sourceo Filename: contiene il nome del file che deve essere letto, (se si scrive solo il nome

del file, JM andrà a cercare quest’ultimo nella stessa cartella in cui è salvato lo script), altrimenti e sempre meglio scrivere un path fisico.

o Variable Names (comma-delimited): indica il carattere che serve a delimitare i valori all’interno del file nel caso dell’esempio è il punto e virgola “;” utilizzato soprattutto nei file csv creati da excel, mentre OpenOffice di norma utilizza la virgola. Nel resto dello script per poter richiamare le variabili sarà sufficiente chiamarla con il ${nomeVariabile} es: ${username}Nota: questo elemento legge sia i file csv, o comunque qualsiasi tipo di file di testo che rispetti la formattazione csv. Bisogna inoltre stare attenti al tipo di delimitatore nel caso in cui di utilizzi Excel od OpenOffice.

o Recycle on EOF?: Valore booleano che se settato a TRUE permette di ri-leggere i valori del file dalla prima riga, una volta che si raggiunge l’EOF (end of file).

o Stop thread on EOF?: valore booleano che permette di indicare nel caso il ri-ciclo sia impostato a FALSE, di fermare il thread.

o Sharing Mode:

All threads: il file è condiviso tra tutti i threads (locali); Current thread group: ogni file è aperto una volta per ogni thread group

nella quale gli elementi appaiono; Current thread: ogni file è aperto separatamente per ogni thread; Identifier: tutti i threads condividono lo stesso identificativo condividendo lo

stesso file;

Di default, il file è aperto solo una volta, ed ogni thread utilizzerà una riga diversa del file stesso. Le linee sono lette all’inizio di ogni iterazione. Perciò ogni variabile è definita all’inizio di ogni iterazione del test, permettendo di utilizzare poi le variabili in quasi tutti gli elementi di JM.

Quando la fine del fine è stata raggiunta (End Of File EOF), ed è impostata la scelta di ri-ciclare a gli elementi “vero”, JM ricomincerà di nuovo dall’inizio la lettura del file dalla prima linea. Altrimenti se

Se invece l’opzione di ri-ciclo è impostata a “false”, cosi come l’opzione di stopThread, allora tutte le variabili sono settate alla <EOF> quando la fine del file è raggiunta.

Se invece l’opzione di riciclo è “false”, e lo Stop Thread è “true”, quando si raggiunge l’EOF allora il Thread sarà stoppato.

Logic Controllers

I logic controllers servono a determinare l’ordine in cui i samplers sono processati, oltre a fornire strutture logiche ed il mantenimento ordinamento degli elementi all’interno di JM.

Nota: se un logic controller è disabilitato, tutti gli elementi che sono contenuti al suo interno, non saranno presi in considerazione, in poche parole ereditano anch’essi lo stato “disable”.

>Simple Controller:

Il simple controller è forse uno degli oggetti più semplici, ma allo stesso tempo utilissimo all’interno di JM, infatti pur non offrendo nessuna funzionalità, permette di organizzare i samplers e gli altri Logic Controllers.

>Loop Controller:

Il loop controller come lascia intuire il nome, serve ad eseguire gli elementi al suo interno per un numero di cicli impostato, in aggiunta al numero di cicli (loop) che sono stati specificati all’interno del Thread Group.

Es: se nel mio Thread Group ho impostato che lo script deve ciclare per 3 volte, e all’interno del mio loop controller ho inserito il valore 2. Allora avrò che gli elementi che sono all’interno del loop

count verranno eseguiti per un totale di 3*2 = 6 volte, mentre i restanti elementi saranno ri-eseguiti 3 volte.

Timers

I timers sono degli elementi che permettono di inserire un tempo di pausa all’interno dell’esecuzione dello script, simulando una pausa che potrebbe avvenire all’interno della visita di un sito web. Bisogno notare che i timers sono processati prima di ogni sampler nello scope in cui si trovano, se esistono più samplers nello stesso scope, tutti i timers presenti saranno processati prima dei sampler stessi. Per applicare un timer al singolo sampler è sufficiente inserire il timer come child del sampler stesso, anche se in questo modo il timer verrà processato prima del sampler stesso. Per inserire una pausa dopo un sampler o tra un sampler ed un altro è necessario inserire l’elemento Test Action Sampler.

>Constant Timer:E’ il timer più semplice, infatti la sua unica funzionalità è quella di fermare il thread per un periodo di tempo costante definito in millisecondi.

>Uniform Random Timer:Questo timer pausa ogni thread per un certo periodo di tempo random (il periodo di tempo non ha nessun peso in particolare, perciò tutti i tempi che sono inclusi nell’intervallo hanno la stessa possibilità di accadere).

Random Delay Maximum: è il numero massimo in millisecondi di pausa da effettuare (il valore è randomico).

Constant Delay Offset: Numero di millisecondi di pausa da effettuare in aggiunta al ritardo random.

Perciò alla fine il ritardo sarà la somma del Random Delay e del Constant Delay.

>Gaussian Random Timer:Questo timer pausa ogni thread per un certo periodo di tempo, dove la maggior parte degli intervalli accadono vicino ad un particolare valore. Anche qui il ritardo totale sarà indicato dalla somma del valore indicato della distribuzione gaussiana (compresa tra 0.0 e la deviazione standard 1.0) e il valore dell’off-set.

Sampler

>HTTP Request:

Questo sampler è uno dei più importati in JM, per quanto riguarda i test di applicazioni web, permette di eseguire/inviare chiamate di tipo http/https al server.

Permettendo inoltre di effettuare delle chiamate per ottenere oggetti che sono all’interno del server quali:

Immagini Applets Stylesheets external scripts frames background images (body, table, TD, TR) background sound

NOTA: Per la logica dei test non è necessario caricare altri elementi che non siano le pagine html, infatti bisogna concentrarsi principalmente sulla chiamate e sugli effetti che provoca sul server, evitando di richiamare altri oggetti, per limitare il rumore che possono provocare al test.

I parametri più importanti sono:

Server: dove si inserisce i dominio o l'indirizzo IP del web server, es: www.esempio.com o 192.168.0.1 [senza includere il prefisso http://]

NOTA: nel caso in cui si utilizzi a monte un HTTP Request Defaults, non è necessario inserire questi parametri, a meno che la richiesta che si effettua non sia un'eccezione all’interno del percorso di navigazione, ad esempio la richiesta punta ad un altro sito esterno al nostro web server;

Port: Indica la porta di ascolto del nostro web server;

Connect Timeout: Numero di millisecondi limite che può attendere prima che una connessione sia aperta, passato quel tempo il Thread và in errore. (Richiede Java 1.5 o superiore quando si usa la default java HTTP implementation);

Response Timeout: Numero di millisecondi limite da aspettare perchè una connessione risponda. Passato quel tempo il Thread và in errore. (Richiede Java 1.5 o superiore quando si usa la default java HTTP implementation);

Protocol: i protocollo supportati sono HTTP, HTTPS e FILE, di default è sempre http;

Method: Implementa tutti i metodi di chiamata http, ovviamente anche i soliti GET e POST;

Redirect Automatically: Se impostata, fa in modo che la chiamata non appaia come sample, ma si occupa soltanto di seguire automaticamente il redirect della pagina.Può essere utilizzata solo con GET;

Follow Redirects: Questo comando funziona soltanto se “Redirec Automatically” non è stato abilitato. Se abilitato si occuperà di controllare che la risposta sia un redirect e di seguire la prossima chiamata, la redirect response apparirà come un sample addizionale.NOTA: E' preferibile utilizzare questa impostazione in modo da seguire tutto il percorso che JM effettua durante lo script;

Use multipart/form-data for HTTP POST: permette nel caso di chiamata in post, di abilitare l'utilizzo del metodo multipart/form-data, per l'invio dei file;

Path: il path della risorsa (per esempio /portal/welcome). Se la risorsa richiede parametri per la chiamata, si può utilizzare la sezione “Send Parameters With the Request” che si trova proprio sotto. Nel caso speciale in cui il path cominci con “http://” o “https://”, allora il path si comporta come se fosse la URL completa non tenendo in considerazione sia le informazioni sul server, che sulla porta , che sul protocollo; inoltre i parametri inviati in GET sono ignorati;

Send Parameters With the Request: permette gestire la coppia “nome” e “valore” che devono essere inviati insieme alla richiesta http. Inoltre possiede due opzioni:

Encode? : permette di codificare il parametro passato in entità HTML, es: <a href> viene convertito nella richiesta in “&lt;a href&gt;”; Include Equals : permette di non includere l'uguale nelle chiamate, nel caso in cui il parametro sia vuoto

NOTA IMPORTANTE: Send Parameters With the Request, riesce a gestire solo un tipo di metodo di chiamata (get o post) questo può essere forviante nel caso in cui si abbia una pagina che effettua una chiama in POST, ma allo stesso tempo chieda anche dei parametri in get o più precisamente tramite URL, in questo caso i parametri che devono essere passati nella URL, vanno inseriti nel casella del path (es: /portal/applicazione?id=1&nome=pippo), mentre dovranno essere lasciati intatti i parametri in post.

File Path: Nome del file che deve essere inviato, nel caso in cui sia vuoto il campo, JM non invierà nessun file, al contrario JM automaticamente invierà la richiesta in modalità multipart form request. Nel caso in cui il parametro “Parameter name” (che si trova sotto) sia omesso, allora in quel caso è inviato come il body della richiesta;

Parameter name: nome della richiesta web, legata al file (es: index.html);

MIME Type: mime type, per esempio text/plain o text/pdf;

Retrieve All Embedded Resources from HTML Files: chiede a JM di parsare l'html e di richiedere tutte le risorse associate alla pagina come ad esempio: immagini, css, javascript, ecc..;

Gestione dei Parametri:Per il metodo POST nel caso in cui non vi siano file da inviare, e i nomi dei parametri sono omessi, allora il body è creato dalla concatenazione di tutti i valori dei parametri. Questo permette la creazione di body arbitrari da inviare.

Post Processor (PP)

I Post-Processors sono applicati dopo i sampler. Per l'esatezza sono applicati dopo tutti sampler che si trovano nello stesso scope/livello del PP, perciò per assicurarsi che il PP sia applicato ad un particole sampler è necessario fare in modo che quest’ultimo diventi un child del sample, che si deve monitorare.

>Regular Expression Extractor:

Permette agli utenti di estrarre valori da una chiamata al server, utilizzando una espressione regolare di tipo Perl. Cosi come tutti i post-processor, questo elemento sarà eseguito dopo ogni richiesta del sample che si trovi nello stesso scope/livello.

Caso Reale:Un caso reale di utilizzo, si può avere per esempio nel caso in cui si voglia estrarre un idNode (generato in modo randomico dal sistema, ma sempre seguendo un determinato template che conosciamo) da una tabella di valori. Per poi utilizzare questo valore in un secondo momento, ad esempio, l'invio di questo parametro per l'eliminazione del record tramite URL. E' chiaro che non possiamo utilizzare un file CSV, visto la caratteristica randomica, con qui il sistema crea questi id.

Parametri:

Response Field to check: E' possibile specificare quale campo di risposta prendere in considerazione per eseguire l'estrazione, tra i seguenti:

Body: è il body della pagina, esclusi gli header; Headers: gli header della pagina; URL; Response Code: es 200; Response Message: es OK;

Reference Name: Il nome della variabile che conterrà il risultato, per richiamare la variabile basta soltanto scrivere ${nome variabile scelta};

Regular Expression: l'espressione regolare utilizzata per effettuare il parse della risposta. Questa espressione deve contenere al minimo un set di parentesi per catturare una porzione di stringa.NOTA: la sintassi dell'espressione regolare è di tipo perl, perciò bisogna stare attenti che l'espressione regolare utilizzata sia coerente, magari effettuando delle prove con dei tools appositi;

Template: Indica il gruppo di risultati a cui fare riferimento. Es: $1$ si riferisce al primo gruppo, $2$ si riferisce al secondo gruppo, ecc... Mentre con $0$ indichiamo qualsiasi cosa trovi l'intera espressione regolare;

Match No: indica quale combinazione JM deve utilizzare: 0 (zero): indica una qualsiasi combinazione random; > 0: indica la specifica combinazione da utilizzare;

Default Value: E' un valore di default che deve essere inserito all'interno della variabile nel caso in cui l'espressione regolare per qualche motivo (es: la pagina non contiene la stringa voluta, o l'espressione regolare è incorretta) non riesca ad ottenere nessun valore. Questo valore è molto utilizzato per effettuare un debug sul componente.

NOTA: le espressioni regolari, grazie all'utilizzo delle parentesi tonde permettono di creare gruppi di risultati. Come riporta la schermata di esempio se abbiamo due stringhe di testo che si riferiscono a delle href (Your test string) e la nostra espressione regolare possiede all'interno due gruppi di parentesi. Avremmo come risultato (Match captures) tre gruppi di risultati (tante quante le stringhe che rientrano nella selezione della espressione), mentre all'interno dei gruppi risultati abbiamo a loro volta due gruppi che si riferisce al numero di parentesi tonde utilizzate all'interno dell'espressione stessa.NOTA2: Uno dei siti migliori per provare le espressioni regolari è www.rubular.com

>BeanShell PostProcessor

Questo componente permette di utilizzare il linguaggio di script java BeanShell, visto la mia ignoranza riguardo a questo componente, il suo utilizzo si ferma soltanto a ciò che riguarda la stampa a video di stringhe o variabili.

Molto utile nel caso in cui si voglia effettuare un debug sull’andamento dello script.Con la parola chiave:

Print: è possibile stampare direttamente sulla console dos (che si avvia quando avviamo JM);

Log.(info,warn,error): che permette di stampare all’interno del file jmeter.log.

Questo componente viene eseguito N volte quanti sample sono presenti all’interno del contenitore che lo contiene.

AssersionLe Assertions sono utilizzate per fornire un controllo addizionale sui samplers, i quali sono eseguiti dopo tutti i sample nello stesso scope. Per assicurarsi che l'asserzione sia applicata solo ad un particolare sample, è necessario inserirlo come child del sample stesso.

>Response Assertions:

La response assertions, permette di aggiungere stringhe che dovranno essere comparate con i vari

campi di risposta creati dal sample.

E' possibile utilizzare i pattern:

Contains, Matches: con espressioni regolari in stile perl;

Equals, Substring: testo semplice, case-sensitive;

Not: opzione che nega l’esistenza del pattern scritto, utilizzato ad esempio nel caso si voglia negare l’esistenza della parola “error”.

E' possibile scegliere se la stringa deve corrispondere con l'intera risposta, o se la risposta contiene una parte della stringa stessa. Inoltre è possibile aggiungere asserzioni multipli ad ogni controller per aggiungere flessibilità.

Listener

I Listener sono componenti che permettono all’utente di avere un resoconto sull’andamento dei test.

Ogni singolo Listener, si occupa di generare una reportistica diversa a seconda delle esigenze: qui sotto saranno elencati i listener che possono essere più utili nella fase di test, stando attenti che questi componenti utilizzano molte risorse e perciò non sono consigliabili da utilizzare nel caso di test di carico, o al massimo è bene utilizzarlo con parsimonia.

>Result Tree:

Il Result Tree mostra a video il risultato di ogni chiamata effettuata da JM (ed anche i risultati di eventuali sotto-chiamate se presenti), questo componente anche se molto utile ha un grosso limite, infatti spende un sacco di risorse il che lo rende utile solo nel caso di test piccoli o nel caso di debug del nostro script.

Ogni singola chiamata viene preceduta da un’icona che può essere: Verde, nel caso in cui la chiamata sia andata a buon fine. Rossa, nel caso in cui la chiamata abbia avuto dei problemi, come ad esempio il fallimento

di qualche asserzione.

Nota: Bisogna sempre stare attenti al significato delle icone, in quanto per esempio se una chiamata risulta fallita, per JM, può essere che quella stessa chiamata ha un significato ancora valido per noi all’interno della batteria di test.

Sono presenti 3 schede: Sampler result: Mostra alcune informazioni relative al sample che si stà facendo girare, ed

anche alcune informazioni sulla risposta che ha effettuato il web server; Request: Mostra i parametri che si inviano al web server, come la chiamata URL, i

parametri in post e il valore dei cookie associati; Response Data [!]: Mostra i dati ottenuti dal web server, questa è forse la scheda più

importante in quanto ci mostra le informazioni che vedrebbe un’utente tipo. Potendo vedere la risposta è possibile controllare, in modo visivo come sta andando il test.

Tra le altre possibilità vi è quella di poter fare il rendering dei dati ottenuti, grazie ad un motore interno di:

o Html (senza il supporto del CSS, perciò con una grafica molto spartana);o Json;

o XML;Nel caso in cui i dati trasmessi superino i 200KB non sarà possibile visualizzare i dati, ammeno che non si aumenti il limite nei file di configurazione sotto la voce view.results.tree.max_size.

>View Result in Table

Questo Listener mostra gli stessi dati che sono presenti all’interno di View Result Tree, in forma tabellare e molto più sintetica ed immediata, utile soprattutto se si vuole vedere velocemente l’andamento dei test.

L’informazione più importante è relativa alla colonna “Sample Time(ms)” che mostra il tempo impegato dal web server per rispondere.

>Aggregate Graph

L’aggregate graph, permette di raggruppare le varie informazioni provenienti dai sample, in modo da avere una visione d’insieme sull’andamente dei test, da un punto di vista globale ed aggregato.

Le informazioni della tabella sono:

Label: il nome del sample che si stà raggruppando, è molto importante la scelta del nome del sample, in quanto se una chiamata ad una stessa URL, venisse chiamata in modo differente, JM creerebbe due righe differenti e non aggregherebbe le informazioni;

# Samples: Numeri di sample che sono stati aggregati e processati;

Averege: Media aritmetica dei tempi medi di risposta dell’applicazione;

Median: Mediana aritmetica dei tempi medi di risposta dell’applicazione;

90% line: tempo di risposta medio, in cui si trovano il 90% delle richieste;

Min: minimo tempo di risposta, ottenuto dal gruppo di request;

Max: massimo tempo di risposta, ottenuto dal gruppo di request;

Error %: percentuale di errori ottenuti durante le request;

Throughput: quanti di richieste effettuate nell’arco di secondi, minuti, ore;

Una delle caratteristiche di questo listener è la possibilità di poter creare:

Grafici: riguardante le varie componenti in tabella, direttamente da JM, e di salvare il grafico poi in formato Immagine;

Salvattaggio dei dati in tabella: tramite il formato Csv, utilizzando come separatore la virgole (perciò ottimo per essere letto con OpenOffice), e senza l’intestazione delle colonne.

Nota: per quanto ottimo questo componente, ha un problema di performance, dovuto soprattutto al calcolo delle varie medie, perciò è sconsigliato da utilizzare in test di grosse entità, al suo posto è possibile utilizzare il Summary Report

> Summary Report

Simile all’ aggregate graph, è molto più performante in quanto non deve effettuare dei calcoli di media come ad esempio ma “Mediana” e il “90% line”, permettondo cmq di avere un lista di informazioni aggregate utili sulle request.

In basso nella pagina inoltre è possibile salvare i dati presenti in tabella, sempre in formato CSV, con inoltre la possibilità di inserire l’intestazione delle colonne.

>Simple Data Writer

Questo componente permette di scrivere su di un file (identificato all’interno del box “filename”) in formato CSV o XML, che conterrà varie informazioni sull’andamento dei sample, molto simile in qualchè modo alle informazioni visibili all’interno del listener “View Result in Table”.

Per scegliere quali informazioni dovranno essere salvate all’interno del file è sufficente andare sul bottone “Configure” e selezionare la lista di campi che si desiderano.

Da notare che esistono due tipi di campi: quelli che scrivono l’informazione in formato xml e quello che la scrivono in formato csv, se si sceglie un campo xml e uno csv, si avrà che JM preferirà la scrittura in formato XML, portando pero eventuali discordanze sui dati.

Una delle ottime caratteristiche di questo componente risiedono nel fatto che può scrivere le informazioni su file anche nel caso in cui si esegua JM tramite linea di comando.

Post Processor

Muestras: Cantidad total de veces que se realiza un request.

Media: Media aritmética de los tiempos de respuesta(response time) de la aplicación.

Mediana: Mediana aritmética de los tiempos de respuesta(response time) de la aplicación.

Linea de 90%: Tiempo de respuesta en el que se encuentra el 90% de los requests.

Min: Minimo tiempo de respuesta para el request.

%Error: porcentaje de request con errores

Rendimiento: Es la cantidad de request que el servidor procesa por hora.

Kb/Sec: Cantidad de Kb que el servidor procesa por segundo

Max: Máximo tiempo de respuesta para el request.

The aggregate report creates a table row for each differently named request in your test. For each request, it totals the response information and provides request count, min, max, average, error rate, approximate throughput (request/second) and Kilobytes per second throughput. Once the test is done, the throughput is the actual through for the duration of the entire test.

The thoughput is calculated from the point of view of the sampler target (e.g. the remote server in the case of HTTP samples). JMeter takes into account the total time over which the requests have been generated. If other samplers and timers are in the same thread, these will increase the total time, and therefore reduce the throughput value. So two identical samplers with different names will have half the throughput of two samplers with the same name. It is important to choose the sampler names correctly to get the best results from the Aggregate Report.

Calculation of the Median and 90% Line (90 th percentile ) values requires a lot of memory as details of every Sample have to be saved. See the Summary Report for a similar Listener that does not need so much memory.

Label - The label of the sample. If "Include group name in label?" is selected, then the name of the thread group is added as a prefix. This allows identical labels from different thread groups to be collated separately if required.

# Samples - The number of samples with the same label Average - The average time of a set of results Median - The median is the time in the middle of a set of results. 50% of the samples took

no more than this time; the remainder took at least as long.

90% Line - 90% of the samples took no more than this time. The remaining samples at least as long as this. (90 th percentile )

Min - The shortest time for the samples with the same label Max - The longest time for the samples with the same label Error % - Percent of requests with errors Throughput - the Throughput is measured in requests per second/minute/hour. The time unit

is chosen so that the displayed rate is at least 1.0. When the throughput is saved to a CSV file, it is expressed in requests/second, i.e. 30.0 requests/minute is saved as 0.5.

Kb/sec - The throughput measured in Kilobytes per second

Times are in milliseconds.

Control Panel

Luego podemos encontrar más opciones que no vienen al caso. Ya tenemos definido cuantos usuarios van a correr el escenario y cada cuanto van a estar ingresando en el escenario, solo queda definir donde y como vamos a guardar los resultados, para esto debemos tener algun Listener con el

cual podamos guardar los resultados de las pruebas. Yo uso y recomiendo los listeners “Ver Árbol de Resultados” y “Aggregate Graph“, paso a explicar cada uno:

“Ver Árbol de Resultados” nos permite observar el resultado de cada uno de los requests realizados por JMeter ademas de la pantalla (si aplica) a la que accedio cada request. También nos permite guardar el archivo JTL(escribiendo la ruta absoluta en el textbox) con los resultados de las pruebas, pudiendo configurar este con el boton “Configurar” y seleccionando las opciones que sean relevantes a las pruebas. Segun que seleccionemos podemos guardar el resultado en CSV (recomendado) o XML.

“Aggregate Graph” nos da el plus de obtener los estadisticos de las pruebas (ademas del JTL generado por el control anterior) presionando en el boton “Save Table Data” lo que nos genera un CSV con valores estadisticos como:

Muestras: Cantidad total de veces que se realiza un request.

Media: Media aritmética de los tiempos de respuesta(response time) de la aplicación.

Mediana: Mediana aritmética de los tiempos de respuesta(response time) de la aplicación.

Linea de 90%: Tiempo de respuesta en el que se encuentra el 90% de los requests.

Min: Minimo tiempo de respuesta para el request.

%Error: porcentaje de request con errores

Rendimiento: Es la cantidad de request que el servidor procesa por hora.

Kb/Sec: Cantidad de Kb que el servidor procesa por segundo

Max: Máximo tiempo de respuesta para el request.

Una vez que tenemos los reultados de las pruebas es el momento de pasar el CSV (o XML) con los resultados generales y el CSV con los estadisticos a una planilla (o aplicación) y procesarlos segun nuestro objetivo.