Quali sono le giuste misure, JMeter o Apache ab?

Question

Ho iniziato a scrivere alcuni test di base in JMeter e sono rimasto sorpreso dal fatto che le misurazioni siano così diverse da quelle di Apache ab.

Ho una LAN gigabit che collega un server Intel i7 con Nginx e una macchina di prova i5 con JMeter o ab. Inizialmente, sto semplicemente testando l'out-of-the-box del tasso di risposta della home page Nginx.

ab -c 1 -n 100 http://testserver.local/ 

dà

Document Path:  /
Document Length:  151 bytes 

Concurrency Level:  1 
Time taken for tests: 0.078 seconds 
Complete requests:  100 
Failed requests:  0 
Write errors:   0 
Total transferred:  38400 bytes 
HTML transferred:  15100 bytes 
Requests per second: 1280.77 [#/sec] (mean) 
Time per request:  0.781 [ms] (mean) 
Time per request:  0.781 [ms] (mean, across all concurrent requests) 
Transfer rate:   480.29 [Kbytes/sec] received 

Questo risultato è costantemente riproducibile, +/- una piccola percentuale.

In JMeter, ho un gruppo filo 100-loop 1-utente contenente:

• un'intestazione modificando Accept-Encoding gestore HTTP: gzip
• un HTTP Get/campionatore
• una relazione di sintesi ascoltatore

Con solo 100 campioni, questo dà selvaggiamente risultati incoerenti ogni volta che lo eseguo. Ma il fatto più sorprendente è che il throughput viene segnalato a partire da 40 richieste al secondo (non 1280). Il più alto tasso registrato era 1030, e ciò è stato ottenuto solo quando sono aumentato a 10.000 campioni.

Ho ragione nel pensare che JMeter sia lo strumento sbagliato per test di carico semplici perché i suoi costi generali sono troppo alti per consentire misurazioni accurate?

Answer 1

Jmeter indica per quanto tempo ogni richiesta ha effettivamente preso il valore. AB fa solo alcuni calcoli basilari per ottenere la media generale. Quindi, la risposta diretta alla tua domanda è che jmeter lo fa bene e ab fa solo una supposizione approssimativa dandoti la media su tutto.

Ma, certo, se si mettono i due strumenti fianco a fianco e li si assegna per la velocità, allora è chiaro che ab sta per uscire eseguendo jmeter. Jmeter fa solo di più, registra più dati e sta elaborando più logica, quindi richiede più tempo per girare una singola richiesta. Il semplice fatto è che Jmeter è uno strumento di test di carico completo, AB è, beh, no.

Il fatto è che l'obiettivo di un strumento di test di carico, non è quello di essere il ragazzo più veloce sul blocco, invece si tratta di essere in grado di costruire una rappresentazione realistica del tipo di caricare la vostra applicazione potrebbe essere colpito con quando va in diretta. A questo proposito, jmeter vince a mani basse, quindi dipende davvero da quali sono le vostre esigenze. Se vuoi solo generare quante più richieste possibile utilizzando la minor quantità di hardware allora ab è una buona scelta ma se vuoi costruire un test rappresentativo, con viaggi transazionali, logica condizionale e ogni sorta di altre cose utili, allora jmeter è la strada da percorrere Pensa a questo: sono entrambi progetti Apache, ma AB è stato, penso, progettato per testare il server web Apache, tuttavia, JMeter è stato progettato per testare Tomcat.

Ora, sto indovinando che jmeter stava producendo risultati incoerenti perché stava colpendo un limite sulla macchina su cui era in esecuzione. Scommetto che stavi correndo in modalità GUI e avevi almeno un ascoltatore attivo, come questo stai chiedendo allo strumento di fare molto. Se hai bisogno di un alto tasso di richieste, Jmeter ha una modalità lean e media.In genere, per i grandi volumi è consigliabile eseguire test sulla riga di comando con pochissimi ascoltatori; ci sono molte informazioni su questo argomento sul sito di apache jmeter.

Un altro punto che dovresti considerare, se stai veramente entrando in test di carico, è che per trarre veramente beneficio da questo genere di cose devi prima decidere quale tipo di carico hai bisogno del tuo sito per supportare e solo quindi dovresti progettare un test che rappresenti questo. Questo risultato è ottenuto utilizzando i tempi di attesa stimolati e simulati. Il problema con il raccontare un thread che dovrebbe andare via e correre il più velocemente possibile è che itererà velocemente come le condizioni locali lo consentono, ma ci sarà sempre qualcosa che mette le interruzioni, anche ab è limitato; non importa quanto sia leggero uno strumento, lo fa ancora qualcosa. Ma se segui le tue richieste, rimuovi questo problema e, come bonus aggiuntivo piuttosto utile, finisci con la coerenza tra le esecuzioni e tra le build del codice, quindi anche se il tuo server accelera o rallenta (con modifiche al codice base) il tuo test produrrà comunque lo stesso tasso di richieste - cosa abbastanza utile per il benchmarking.

Se si desidera prendere ulteriormente JMeter, controllare il Constant Throughput Timer e quindi utilizzare più thread per creare il livello di traffico che è necessario rappresentare.

Answer 2

Nella configurazione, JMeter si sta saturando più velocemente di quanto possa saturare il server web.

Si sta eseguendo un server Web C ottimizzato su hardware superiore e si esegue il benchmarking con un'applicazione Java relativamente pesante su hardware inferiore. Il codice macchina C ottimizzato sarà (probabilmente) sempre più veloce rispetto al bytecode Java. JMeter non è in grado di stare al passo con Nginx e quindi ti dà risultati strani in quanto colpisce le limitazioni hardware. Java fa un sacco di cose belle in background che gestiscono le risorse hardware, ma creano anche comportamenti imprevedibili all'utilizzo estremo delle risorse. ApacheBench, d'altra parte, è un programma C abbastanza leggero che può saturare il server e può produrre risultati coerenti perché ha una capacità in eccesso dopo aver saturato il server web.

JMeter è ideale per applicazioni dinamiche pesanti con benchmarking che richiedono un po 'di tempo per elaborare le richieste. Tutti i dati extra forniti sono utili per le app Web simili. Quando si ha a che fare con la gestione di file statici (quasi la cosa più veloce che un server Web può fare) su server Web altamente ottimizzati, è necessario uno strumento abbastanza veloce da tenere il passo.

Answer 3

Come già indicato nella prima risposta, la parola chiave "requisiti". JMeter è la scelta migliore per testare il server che serve le pagine web. Ad esempio, può inviare una sequenza di richieste, generando richieste differenti per ciascuna sequenza, analizza le risposte HTML e carica il contenuto di immagini e script dall'HTML. AB è la scelta migliore per il test dell'API REST, in cui è necessario che il server risponda il più rapidamente possibile e faccia più richiesta possibile, non vi sia alcuna connessione tra due richieste sequenziali ed ecc. Quindi, AB è effettivamente in grado di generare più richieste rispetto a JMeter rispetto allo stesso server dalla stessa macchina client.