Esecuzione di un test di stress sull'applicazione Web?

In passato, ho usato lo strumento di stress delle applicazioni Web Microsoft e Pylot per stressare le applicazioni Web. Avevo scritto una semplice home page, uno script di accesso e una procedura dettagliata del sito (in un sito di e-commerce aggiungendo alcuni articoli a un carrello e alla cassa).

Colpire duramente l'homepage con una manciata di sviluppatori avrebbe quasi sempre individuato un grosso problema. Altri problemi di scalabilità emergerebbero nella seconda fase, e ancora di più - dopo il lancio.

L'URL degli strumenti che ho usato erano Microsoft Homer (aka Microsoft Web Application Stress Tool ) e Pylot .

I rapporti generati da questi strumenti non hanno mai avuto molto senso per me e passerei molte ore a cercare di capire quale tipo di carico simultaneo il sito sarebbe in grado di supportare. Ne è sempre valsa la pena perché i bug e i colli di bottiglia più stupidi sarebbero sempre emersi (ad esempio, configurazioni errate del web server).

Che cosa hai fatto, quali strumenti hai usato e che successo hai avuto con il tuo approccio? La parte che è più interessante per me è trovare una sorta di formula significativa per calcolare il numero di utenti simultanei che un'app può supportare dai numeri riportati dall'applicazione dello stress test.

Ecco un altro voto per JMeter .

JMeter è uno strumento di test del carico open source, scritto in Java. È in grado di testare diversi tipi di server (ad esempio Web, servizi Web, database, praticamente tutto ciò che utilizza sostanzialmente le richieste).

Tuttavia, una volta che inizi a fare test complicati ha una curva di apprendimento ripida, ma ne vale la pena. È possibile iniziare a correre molto rapidamente e, a seconda del tipo di stress test che si desidera fare, potrebbe andare bene.

Professionisti:

• Strumento Open-Source / gratuito dal progetto Apache (aiuta con il buy-in)
• Facile da iniziare e facile da usare dopo aver compreso i concetti chiave. (Cioè, come creare una richiesta, come creare un'asserzione, come lavorare con le variabili ecc.).
• Molto scalabile Ho eseguito test con 11 macchine che generano carico sul server per quasi un milione di accessi / ora. È stato molto più facile da installare di quanto mi aspettassi.
• Ha una comunità attiva e buone risorse per aiutarti a metterti in funzione. Leggi prima i tutorial e gioca per un po '.

Contro:

• L'interfaccia utente è scritta in Swing. (Ugh!)
• JMeter funziona analizzando il testo di risposta restituito dal server. Quindi, se stai cercando di convalidare qualsiasi tipo di comportamento javascript, sei sfortunato.
• La curva di apprendimento è ripida per i non programmatori. Se hai familiarità con le espressioni regolari, sei già in anticipo sul gioco.
• Ci sono un gran numero di idioti ( inserire esplicativi ) nel forum di supporto che fanno domande stupide che potrebbero essere facilmente risolte se dessero alla documentazione anche uno sguardo superficiale. ('Come uso JMeter per eseguire lo stress test della mia GUI di Windows' appare abbastanza frequentemente).
• La segnalazione "pronta all'uso" lascia molto a desiderare, in particolare per test più grandi. Nel test che ho menzionato sopra, ho finito per scrivere un'app di console rapida per fare alcune conversioni da "xml-logfile" a "html". Questo è successo qualche anno fa, quindi è probabile che ciò non sarebbe più necessario.

Ho usato The Grinder . È open source, abbastanza facile da usare e molto configurabile. È basato su Java e utilizza Jython per gli script. Lo abbiamo eseguito contro un'applicazione Web .NET, quindi non pensare che sia uno strumento solo Java (per loro natura, qualsiasi strumento di stress web non dovrebbe essere legato alla piattaforma che utilizza).

Abbiamo fatto alcune cose ordinate con esso ... eravamo un'applicazione di telecomunicazione basata sul web, quindi un uso interessante che ho impostato è stato quello di imitare la composizione di un numero attraverso la nostra applicazione Web, quindi abbiamo usato uno strumento di risposta automatica che avevamo (che era fondamentalmente un tutorial app da Microsoft per connettersi al proprio server LCS RTC ... che è ciò a cui Microsoft Office Communicator si connette su una rete locale ... quindi modificato per rispondere automaticamente alle chiamate). Questo ci ha quindi permesso di utilizzare questo invece di un costoso strumento di telefonia chiamato The Hammer (o qualcosa del genere).

Comunque, abbiamo anche usato lo strumento per vedere come la nostra applicazione resisteva a carichi elevati ed era molto efficace nel trovare i colli di bottiglia. Lo strumento ha integrato i rapporti per mostrare quanto tempo impiegano le richieste, ma non l'abbiamo mai usato. I registri possono anche archiviare tutte le risposte e quant'altro, o la registrazione personalizzata.

Consiglio vivamente questo strumento, molto utile per il prezzo ... ma mi aspetto di fare una configurazione personalizzata con esso (ha un proxy incorporato per registrare uno script, ma potrebbe essere necessario personalizzare per catturare qualcosa come sessioni ... Lo so Ho dovuto personalizzarlo per utilizzare una sessione unica per thread).

Un po 'in ritardo per questa festa. Concordo sul fatto che Pylot sia il miglior strumento open source emergente. È semplice da usare ed è attivamente lavorato da un bravo ragazzo ( Corey Goldberg ). Come fondatore di OpenQA , sono anche felice che Pylot sia elencato sulla nostra home page e utilizzi alcune delle nostre infrastrutture (vale a dire i forum).

Tuttavia, di recente ho anche deciso che l'intero concetto di test del carico era imperfetto: emulare il traffico HTTP, con applicazioni così complesse come sono diventate, è una seccatura. Ecco perché ho creato lo strumento commerciale BrowserMob. È un servizio di test del carico esterno che utilizza Selenium per controllare i browser Web reali durante la riproduzione del carico.

L'approccio richiede ovviamente una tonnellata più hardware rispetto alle normali tecniche di test di carico, ma l'hardware è in realtà piuttosto a buon mercato quando si utilizza il cloud computing. E un piacevole effetto collaterale di questo è che lo scripting è molto più semplice del normale test di carico. Non è necessario eseguire alcuna corrispondenza regex avanzata (come richiede JMeter) per estrarre i cookie, lo stato della sessione .NET, i parametri di richiesta Ajax, ecc. Dato che stai utilizzando browser reali, fanno semplicemente quello che dovrebbero fare.

Mi dispiace lanciare apertamente un prodotto commerciale, ma spero che il concetto sia interessante per alcune persone e almeno li induca a pensare a nuovi modi per gestire i test di carico quando si ha accesso a un mucchio di hardware aggiuntivo!

Ho usato JMeter . Oltre a testare il server Web, è anche possibile testare il back-end del database, i servizi di messaggistica e i server di posta elettronica.

ab , l'assedio , Tsung , httperf , Travolgere , Pylot, richiesta-log-analizzatore , perftools

Per un semplice utilizzo, utilizzo ab (apache benchmark) e assedio, in seguito ne è necessario uno in quanto ab non supporta i cookie e creerebbe sessioni infinite dal sito dinamico.

entrambi sono semplici da avviare:

ab -c n -t 30 url

siege -b -c n -t 30s url

l'assedio può essere eseguito con più URL.

l'ultima versione di assedio si trasforma in siegerc in dettaglio, il che è fastidioso. puoi disabilitarlo solo modificando quel file ( /usr/local/etc/siegerc).

Per un servizio basato sul Web, controlla loader.io .

Sommario:

loader.io è un servizio di test del carico gratuito che ti consente di sottoporre a stress test le tue app / API Web con migliaia di connessioni simultanee.

Hanno anche un'API .

Dato che questa domanda è ancora aperta, potrei anche ponderare.

La buona notizia è che negli ultimi 5 anni gli strumenti Open Source sono davvero maturati e decollati nello spazio, la cattiva notizia è che ce ne sono così tanti là fuori.

Ecco i miei pensieri: -

Jmeter vs Grinder

Jmeter è guidato da una specifica di stile XML, costruita tramite una GUI.

Grinder utilizza gli script Jython all'interno di un framework Java muti-thread, quindi più orientato ai programmatori.

Entrambi gli strumenti gestiranno HTTP e HTTPS e avranno un registratore proxy per iniziare. Entrambi gli strumenti utilizzano il modello Controller per guidare più agenti di test, quindi la scalabilità non è un problema (dato accesso al Cloud).

Che è migliore:-

Una dura chiamata in quanto la curva di apprendimento è ripida con entrambi gli strumenti quando si affrontano i requisiti di scripting più complicati per la riscrittura, la correlazione dell'URL, la fornitura di dati unici per Utente virtuale e la simulazione della prima volta o della restituzione degli Utenti (manipolando le intestazioni HTTP).

Detto questo, vorrei iniziare con Jmeter poiché questo strumento ha un enorme seguito e ci sono molti esempi e tutorial sul web per l'utilizzo di questo strumento. Se e quando arrivi a un "blocco stradale", è qualcosa che non puoi "facilmente" fare con Jmeter, allora dai un'occhiata al Grinder. La buona notizia è che entrambi questi strumenti hanno lo stesso requisito Java e una soluzione "mix and match" non è fuori discussione.

Qualcosa di nuovo da aggiungere: i browser senza testa che eseguono più istanze di Selenium WebDriver.

Si tratta di un approccio relativamente nuovo perché si basa sulla disponibilità di risorse che possono ora essere fornite dal cloud. Con questo approccio viene preso ed eseguito uno script Selenium (WebDriver) all'interno di un browser senza testa (ovvero WebDriver = New HtmlUnitDriver ()) in più thread.

Dall'esperienza di circa 25 istanze di "browser senza testa", Amazon Small Small Instance può essere eseguito.

Ciò significa che tutti i problemi di correlazione e riscrittura degli URL scompaiono quando si riutilizzano gli script di test funzionali per diventare script di test delle prestazioni.

La scalabilità è compromessa in quanto saranno necessarie più macchine virtuali per gestire il carico, rispetto a un driver HTTP come Grinder o Jmeter. Detto questo, se stai cercando di guidare 500 Utenti Virtuali, allora con 20 Piccole Istanze Amazon (6 centesimi l'ora ciascuna) al costo di soli $ 1,20 l'ora ti dà un carico molto vicino alla Real User Experience.

Inoltre, v'è un impressionante open-source pure-python distribuito e scalabile locuste un'infrastruttura che utilizza greenlets . È fantastico nel simulare un'enorme quantità di utenti simultanei.

Di recente abbiamo iniziato a utilizzare Gatling per i test di carico. Consiglio vivamente di provare questo strumento per i test di carico. Avevamo usato SOASTA e JMETER in passato. Il nostro motivo principale per considerare Gatling è il seguente:

• Registratore per registrare lo scenario
• Utilizzando Akka e Netty, che offre prestazioni migliori rispetto al modello di threading Jmeter
• DSL Scala che è molto gestibile rispetto a Jmeter XML
• Facile scrivere i test, non spaventarti se è scala.
• segnalazione

Lascia che ti dia un semplice esempio per scrivere il codice usando Gatling Code:

// your code starts here  
val scn = scenario("Scenario")  
     .exec(http("Page")
     .get("http://example.com")) 
// injecting 100 user enter code here's on above scenario.   
setUp(scn.inject(atOnceUsers(100)))       

Tuttavia puoi renderlo il più complicato possibile. Una delle caratteristiche che si distingue per Gatling è la segnalazione che è molto dettagliata.

Ecco alcuni link:
Gatling
Gatling Tutorial

Di recente ho tenuto un discorso al riguardo, puoi consultare il discorso qui:
https://docs.google.com/viewer?url=http%3A%2F%2Ffiles.meetup.com%2F3872152%2FExploring-Load-Testing-with -Gatling.pdf

Questa è una vecchia domanda, ma penso che le soluzioni più recenti meritino una menzione. Acquista LoadImpact: http://www.loadimpact.com .

Ho provato WebLoad è uno strumento abbastanza pulito. Viene fornito e testato l'IDE dello script che consente di registrare le azioni dell'utente su un sito Web. Disegna anche un grafico mentre esegue lo stress test sul tuo server web. Provalo, lo consiglio vivamente.

Provando tutto quanto menzionato qui, ho trovato il curl-loader il migliore per i miei scopi. interfaccia molto semplice, monitoraggio in tempo reale, statistiche utili, da cui costruisco grafici delle prestazioni. Tutte le funzionalità di libcurl sono incluse.

Blaze meter ha un'estensione cromata per le sessioni di registrazione ed esportazione in JMeter (attualmente richiede il login). Hai anche la possibilità di pagare loro i soldi per eseguirli sul loro cluster di server JMeter (il loro prezzo sembra molto meglio di LoadImpact che ho appena smesso di usare):

• Estensione di BlazeMeter per Chrome
• Post di blog a riguardo

Non ho alcuna associazione con loro, mi piace l'aspetto del loro servizio, anche se non ho ancora usato la versione a pagamento.

Hai fatto questa domanda quasi un anno fa e non so se stai ancora cercando un altro modo di confrontare il tuo sito web. Tuttavia, poiché questa domanda non è ancora contrassegnata come risolta, vorrei suggerire il servizio web gratuito LoadImpact (tra cui non affiliato). Ho appena ricevuto questo link via Twitter e vorrei condividere questa scoperta. Creano una buona panoramica ragionevole e per qualche dollaro in più ottieni la "modalità a impatto totale". Questo probabilmente suona strano, ma buona fortuna a spingere e frenare il tuo servizio :)

Ho trovato IBM Page Detailer anche uno strumento interessante con cui lavorare.

Ho usato openSTA .

Ciò consente di registrare una sessione con un sito Web e quindi riprodurla tramite un linguaggio di script relativamente semplice.

Puoi facilmente testare i servizi web e scrivere i tuoi script.

Ti consente di mettere insieme gli script in un test come desideri e configurare il numero di iterazioni, il numero di utenti in ciascuna iterazione, il tempo di accelerazione per introdurre ogni nuovo utente e il ritardo tra ogni iterazione. I test possono anche essere programmati in futuro.

È open source e gratuito.

Produce una serie di rapporti che possono essere salvati in un foglio di calcolo. Quindi utilizziamo una tabella pivot per analizzare e rappresentare graficamente i risultati.

Usiamo lo strumento Microsoft menzionato - Strumento per lo stress delle applicazioni Web Microsoft. È lo strumento più semplice che abbia mai usato. È limitato in molti modi, inclusa la possibilità di colpire solo la porta 80 nei test creati manualmente. Ma la sua facilità d'uso significa che viene effettivamente utilizzato.

Integriamo il carico di questo strumento con altri strumenti tra cui OpenSTA e spider di controllo dei collegamenti.

JMeter sembra buono dalla mia valutazione iniziale, spero di includerlo nella nostra continua integrazione in futuro. Ma JMeter è complesso e non banale da implementare.

Suggerirei di aprire un'altra domanda sull'interpretazione dei risultati dello strumento di stress per la SM.

Visual Studio Test Edition 2010 (anche il 2008 buono). Questo è uno strumento davvero semplice e potente con cui creare test web / di carico.

Il vantaggio di questo strumento quando si utilizza su server Windows è che si ottiene l'accesso integrato a tutte le statistiche del server perfmon nel report. Davvero utile.

L'altro vantaggio è che con il progetto Visual Studio è possibile integrare una "Performance Session" che profilerà l'esecuzione del codice del tuo sito Web.

Se stai offrendo pagine Web da un server Windows, questo è lo strumento migliore in circolazione.

Tuttavia, è necessaria una licenza separata e costosa per utilizzare più macchine per caricare test dell'applicazione.

Abbiamo sviluppato un processo che considera il carico e la misurazione delle prestazioni come una preoccupazione di prima classe - come dici tu, lasciarlo alla fine del progetto tende a deludere ...

Quindi, durante lo sviluppo, includiamo test multiutente di base (usando il selenio), che verifica la follia di base come la gestione della sessione interrotta, ovvi problemi di concorrenza e ovvi problemi di contesa di risorse. I progetti non banali includono questo nel processo di integrazione continua, quindi riceviamo feedback molto regolari.

Per i progetti che non hanno requisiti di prestazione estremi, includiamo i test di prestazione di base nei nostri test; di solito, eseguiamo lo scripting dei test utilizzando BadBoy e li importiamo in JMeter, sostituendo i dettagli di accesso e altre cose specifiche del thread. Quindi li aumentiamo fino al livello in cui il server gestisce 100 richieste al secondo; se il tempo di risposta è inferiore a 1 secondo, di solito è sufficiente. Lanciamo e andiamo avanti con le nostre vite.

Per progetti con requisiti di prestazioni estreme, utilizziamo ancora BadBoy e JMeter, ma mettiamo molta energia nella comprensione dei colli di bottiglia sui server del nostro banco di prova (server Web e database, in genere). C'è un buon strumento per analizzare i log degli eventi di Microsoft che aiuta molto in questo. In genere troviamo strozzature impreviste, che ottimizziamo se possibile; che ci fornisce un'applicazione la più veloce possibile su "1 web server, 1 database server". Di solito quindi implementiamo la nostra infrastruttura di destinazione e utilizziamo uno dei servizi "Jmeter in the cloud" per rieseguire i test su larga scala.

Ancora una volta, i report PAL aiutano ad analizzare ciò che è accaduto durante i test: spesso si riscontrano strozzature molto diverse negli ambienti di produzione.

La chiave è assicurarsi non solo di eseguire gli stress test, ma anche di raccogliere le informazioni necessarie per comprendere le prestazioni dell'applicazione.

Ci sono molti buoni strumenti menzionati qui. Mi chiedo se gli strumenti rispondano alla domanda: "Come si fa a stressare un'applicazione Web?" Gli strumenti non forniscono realmente un metodo per sottolineare un'app Web. Ecco quello che so:

I test di stress mostrano come un'app Web non funziona durante la risposta a una popolazione crescente di utenti. Le prove di stress mostrano come funziona l'app Web mentre fallisce. La maggior parte delle app Web di oggi, in particolare le app Web sociali / mobili, sono integrazioni di servizi. Ad esempio, quando Facebook è stata interrotta nel maggio 2011, non è stato possibile accedere all'app Web di Pepsi.com. L'app non ha fallito del tutto, solo una grande parte della sua normale funzione non è disponibile per gli utenti.

Il test delle prestazioni mostra la capacità di un'app Web di mantenere i tempi di risposta indipendentemente dal numero di utenti che utilizzano contemporaneamente l'app. Ad esempio, un'app che gestisce 10 transazioni al secondo con 10 utenti simultanei dovrebbe gestire 20 transazioni al secondo a 20 utenti. Se l'app gestisce meno di 20 transazioni al secondo, i tempi di risposta aumentano e l'app non è in grado di raggiungere una scalabilità lineare.

Inoltre, nell'esempio precedente il conteggio delle transazioni al secondo dovrebbe riguardare solo le operazioni riuscite di un caso d'uso / flusso di lavoro di prova. Gli errori si verificano in genere in intervalli di tempo più brevi e rendono la misurazione del TPS eccessivamente ottimistica. Gli errori sono importanti per uno stress e un test delle prestazioni poiché generano carico anche sull'app.

Ho scritto la metodologia PushToTest nella Guida dell'utente di TestMaker all'indirizzo http://www.pushtotest.com/pushtotest-testmaker-6-methodology . TestMaker è disponibile in due versioni: Open Community (GPL) versione Community e TestMaker Enterprise (commerciale con un ottimo supporto professionale).

-Franco

Dai un'occhiata a LoadBooster ( https://www.loadbooster.com ). Utilizza il browser PhantomJS / CasperJs senza script e senza script per testare i siti Web. Phantomjs analizzerà e renderizzerà ogni pagina, eseguirà lo script sul lato client. L'approccio del browser senza testa è più facile da scrivere scenari di test per supportare complesse app AJAX Web 2.0 navigation navigazione del browser, clic del mouse e sequenze di tasti nel browser o attendere fino a quando non esiste un elemento in DOM. LoadBooster supporta anche lo script HTML selenio.

Disclaimer: lavoro per LoadBooster.

Prova ZebraTester che è molto più facile da usare rispetto a jMeter. Ho usato jMeter per molto tempo ma il tempo totale di impostazione per un test di carico è sempre stato un problema. Sebbene ZebraTester non sia open source, il tempo che ho risparmiato negli ultimi sei mesi lo compensa. Hanno anche un portale SaaS che può essere utilizzato per eseguire rapidamente test utilizzando i loro generatori di carico.

Un'altra nota, per la nostra applicazione web, ho scoperto che avevamo enormi problemi di prestazioni a causa della contesa tra i thread sui blocchi ... quindi la morale era pensare molto attentamente allo schema di blocco. Abbiamo finito con avere thread di lavoro per limitare troppe richieste utilizzando un gestore http asincrono, altrimenti l'applicazione sarebbe semplicemente sopraffatta, si arresterebbe in modo anomalo e bruciava. Significava che un enorme arretrato poteva accumularsi, ma almeno il sito sarebbe rimasto in piedi.

Dai un'occhiata a TestComplete .

Secondo il suggerimento di opensta. Vorrei solo aggiungere che ti permette di fare cose per monitorare il server che stai testando usando SMTP. Teniamo traccia del carico del processore, della memoria utilizzata, dei byte inviati, ecc. L'unico aspetto negativo è che se trovi qualcosa che viene bloccato e vuoi fare una correzione, si basa su diverse librerie open-source che non vengono più mantenute, quindi ottenere una compilazione la versione del sorgente è più complicata rispetto alla maggior parte degli OSS.

Ho suonato con JMeter. Si potrebbe pensare che non sia stato possibile testare i moduli Web ASP.NET. Il viewstate ha rotto i miei test. Non so perché, ma ci sono un paio di strumenti là fuori che non gestiscono viewstate nel modo giusto. Il mio progetto attuale è ASP.NET MVC e JMeter funziona bene con esso.

Ho avuto buoni risultati con FunkLoad :

• interazione utente facile da script
• i rapporti sono chiari
• può monitorare il carico del server

A rischio di essere accusato di autopromozione spudorata, vorrei sottolineare che nella mia ricerca di uno strumento di test del carico gratuito sono andato a questo articolo: http://www.devcurry.com/2010/07/10-free- strumenti-to-loadstress-test-your.html

O non sono riuscito a ottenere il rendimento che volevo, o non sono riuscito a ottenere la flessibilità che desideravo. E volevo aggregare facilmente i risultati di più host di generazione di test di carico nell'analisi post test.

Ho provato tutti gli strumenti della lista e con mia grande frustrazione ho scoperto che nessuno di loro ha fatto quello che volevo essere in grado di fare. Quindi ne ho costruito uno e lo sto condividendo.

Eccolo qui: http://sourceforge.net/projects/loadmonger

PS: Nessun commento malizioso sul nome da parte di persone che hanno familiarità con il gergo urbano. Non ero ma sono leggermente più mondano ora.

Voto anche per jMeter e voglio aggiungere alcune citazioni alla risposta di @PeterBernier.

La domanda principale a cui rispondono i test di carico è quanti utenti simultanei può supportare la mia applicazione Web? Al fine di ottenere una risposta adeguata, i test di carico dovrebbero rappresentare il reale utilizzo dell'applicazione, il più vicino possibile .

Tieni presente quanto sopra, jMeter ha molti blocchi di controllo logici , elementi di configurazione , pre-processori , ascoltatori ... che possono aiutarti in questo.

Puoi imitare la situazione del mondo reale con jMeter, ad esempio puoi:

1. Configurare jMeter di agire come vero e proprio browser configurando ( concurrent resource download, browser cache, http headers, setting request time out, cookie management, https support, encoding, ajax support, ...)
2. Configurare jMeter per generare le richieste degli utenti (attraverso la definizione number of users per second, ramp-up time, scheduling, ...)
3. Configura molti client con jMeter su di essi, per eseguire un test di carico distribuito.
4. Elaborare la risposta per scoprire se il server risponde correttamente durante il test. (Ad esempio assertrisposta per trovare un testo in esso)

Si prega di prendere in considerazione:

• È facile avviare un vero test dell'applicazione web con jMeter in pochi minuti. JMeter ha uno strumento molto semplice che registra il tuo scenario di test (noto come HTTP(S) Test Script Recorder).
• jMeter ha molti plugin su http://jmeter-plugins.org .
• L'interfaccia utente di jMeter è basata su swing e ha apportato buone modifiche a jMeter 3.2. D'altra parte, tieni presente che la GUI di JMeter deve essere utilizzata solo per test e debug. Non è buona norma utilizzarlo in modalità GUI per il test effettivo. https://www.blazemeter.com/blog/5-ways-launch-jmeter-test-without-using-jmeter-gui . Configura e testa il tuo scenario ed eseguilo in modalità non gui.
• Ci sono molti rapporti che mostrano strumenti in jMeter (noto come listeners) ma non sono pensati per essere attivi durante il test. È necessario eseguire il test e generare report ( .jtlfile). Quindi è necessario utilizzare questi strumenti per analizzare il risultato. Dai un'occhiata a https://www.blazemeter.com/blog/jmeter-listeners-part-1-basic-display-formats o https://www.tutorialspoint.com/jmeter/jmeter_listeners.htm .

Il https://www.blazemeter.com/jmeter ha informazioni molto buona e pratica per aiutare a configurare l'ambiente di test.