Apache Bench - Guida rapida
I test delle prestazioni si sono rivelati fondamentali per il successo di un'azienda. Un sito con prestazioni scadenti non solo deve affrontare perdite finanziarie, ma a volte può anche portare a ripercussioni legali.
Nessuno vuole sopportare un sito lento e inaffidabile in importanti interazioni online come acquisti, test online, pagamento delle bollette, ecc. Con Internet così ampiamente disponibile, la gamma di alternative è immensa. È più facile perdere clienti che acquisirli e le prestazioni sono un punto di svolta fondamentale.
Necessità di uno strumento di verifica del carico
Se riusciamo a capire qual è la necessità di uno strumento di test di carico, ci darà la ragione e la motivazione per usarlo. Alcuni famosi siti aziendali hanno subito gravi tempi di inattività quando ottengono un gran numero di visitatori. I siti web di e-commerce investono molto in campagne pubblicitarie, ma non nel test di carico. Pertanto, non riescono a garantire prestazioni di sistema ottimali, quando il marketing porta traffico.
Un altro esempio familiare di ignorare il test di carico è quello di "errore durante la creazione della connessione" nei siti Web WordPress. Pertanto, è una buona idea caricare testare un sito Web o un'applicazione prima della sua distribuzione in produzione. È bello stabilire rapidamente lo scenario migliore per un progetto prima di eseguire test più dettagliati lungo la strada.
Cos'è Apache Bench?
Apache Bench (ab) è uno strumento dell'organizzazione Apache per il benchmarking di un server Web HTTP (Hypertext Transfer Protocol). Sebbene sia progettato per misurare le prestazioni del server Web Apache, può anche essere utilizzato per testare qualsiasi altro server Web altrettanto valido. Con questo strumento, puoi sapere rapidamente quante richieste al secondo è in grado di servire il tuo server web.
Caratteristiche di Apache Bench
Vediamo le caratteristiche e i limiti importanti di Apache Bench. Le caratteristiche e le limitazioni sono elencate di seguito:
Essendo un software open source, è disponibile gratuitamente.
È un semplice programma per computer a riga di comando.
È uno strumento indipendente dalla piattaforma. Significa che può essere invocato su Linux / Unix o su Windows server altrettanto bene.
Può eseguire test di carico e prestazioni solo per il server Web: HTTP o HTTPS.
Non è estensibile.
Apache Bench utilizza un solo thread del sistema operativo indipendentemente dal livello di concorrenza (specificato dal flag -c). Pertanto, durante il benchmarking di server ad alta capacità, una singola istanza di Apache Bench può essere essa stessa un collo di bottiglia. Per saturare completamente l'URL di destinazione, è meglio utilizzare istanze aggiuntive di Apache Bench in parallelo, se il tuo server ha più core del processore.
Precauzione
È necessario essere consapevoli del fatto che non esiste alcuna direttiva in Apache Bench per aumentare la concorrenza in determinati intervalli durante l'esecuzione dei test. Pertanto, eseguire test di carico utilizzando ab equivale a un attacco Denial of Service (DOS). Si consiglia di informare e ottenere l'autorizzazione preventiva dal proprio fornitore di servizi VPS se si intende eseguire test di carico pesante per un lungo periodo di tempo. Ti assegneranno un intervallo di tempo appropriato o sposteranno il tuo nodo per l'attività di test di carico.
In secondo luogo, se stai testando il sito web di una terza persona continuamente e per molto tempo solo per imparare Apache Bench dal tuo VPS (che diventa il nodo di test), c'è una remota possibilità che il tuo IP pubblico VPS possa essere bloccato dal sito web della terza persona permanentemente. In tal caso, non sarai in grado di connetterti a quel sito Web con lo stesso IP. Ma se in futuro vuoi davvero connetterti al sito Web, l'unica soluzione sarà parlare con l'amministratore di sistema del sito Web di destinazione o creare una nuova istanza del server con un IP diverso con l'aiuto del tuo fornitore di servizi VPS.
Dopo averti avvertito, lascia che ti assicuri che tutti i test in questo tutorial sono abbastanza sicuri e fuori da ciò che gli amministratori di sistema chiamano generalmente pratiche di "abuso del sistema".
In questo capitolo, ti guideremo come configurare il tuo ambiente per Apache Bench sul tuo VPS.
Requisito del sistema
Memory - 128 MB
Disk Space - Nessun requisito minimo
Operating System - Nessun requisito minimo
Installazione di Apache Bench
Apache Bench è un'applicazione autonoma e non ha dipendenze dall'installazione del server Web Apache. Quello che segue è un processo in due fasi per installare Apache Bench.
Step 1 - Aggiorna il database dei pacchetti.
# apt-get update
Si noti che il simbolo # prima di un comando da terminale significa che l'utente root sta emettendo quel comando.
Step 2 - Installa il pacchetto apache2 utils per ottenere l'accesso ad Apache Bench.
# apt-get install apache2-utils
Apache Bench è ora installato. Se vuoi testare un'applicazione web ospitata sullo stesso VPS, allora è sufficiente installare solo il server web Apache -
# apt-get install apache2
Essendo un'utilità Apache, Apache Bench viene installato automaticamente durante l'installazione del server Web Apache.
Verifica dell'installazione da banco di Apache
Vediamo ora come verificare l'installazione da banco di Apache. Il codice seguente aiuterà a verificare l'installazione:
# ab -V
Output
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Quando vedi l'output del terminale sopra, significa che hai installato con successo Apache Bench.
Creazione di un utente Sudo privilegiato
Dal punto di vista della sicurezza, è considerata una buona pratica per l'amministratore di sistema creare un utente sudo invece di lavorare come root. Creeremo un utente di prova, denominato test, per lo scopo:
# useradd -m -d /home/test -g sudo test
Impostiamo la password per il nuovo utente -
# passwd test
Il sistema richiederà una nuova password per il test utente. È possibile immettere una semplice password poiché stiamo solo testando e non distribuendo sul server di produzione. Di solito il comando sudo ti chiederà di fornire la password utente sudo; si consiglia di non utilizzare password complicate poiché il processo diventa macchinoso.
Output
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Test del sito web Apache.org
In questa sezione, testeremo il sito Web Apache.org. Passiamo prima al test utente sudo -
# su test
Per cominciare, testeremo il sito Web dell'organizzazione Apache, https://www.apache.org/. Per prima cosa eseguiremo il comando, quindi comprenderemo l'output -
$ ab -n 100 -c 10 https://www.apache.org/
Qui -nè il numero di richieste da eseguire per la sessione di benchmarking. L'impostazione predefinita è eseguire solo una singola richiesta che di solito porta a risultati di benchmarking non rappresentativi.
E -cè la concorrenza e denota il numero di più richieste da eseguire contemporaneamente. L'impostazione predefinita è una richiesta alla volta.
Quindi, in questo test, Apache Bench effettuerà 100 richieste con concorrenza 10 al server dell'organizzazione Apache.
Output
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking www.apache.org (be patient).....done
Server Software: Apache/2.4.7
Server Hostname: www.apache.org
Server Port: 443
SSL/TLS Protocol: TLSv1.2,ECDHE-RSA-AES256-GCM-SHA384,2048,256
Document Path: /
Document Length: 58769 bytes
Concurrency Level: 10
Time taken for tests: 1.004 seconds
Complete requests: 100
Failed requests: 0
Total transferred: 5911100 bytes
HTML transferred: 5876900 bytes
Requests per second: 99.56 [#/sec] (mean)
Time per request: 100.444 [ms] (mean)
Time per request: 10.044 [ms] (mean, across all concurrent requests)
Transfer rate: 5747.06 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 39 46 30.9 41 263
Processing: 37 40 21.7 38 255
Waiting: 12 15 21.7 13 230
Total: 77 86 37.5 79 301
Percentage of the requests served within a certain time (ms)
50% 79
66% 79
75% 80
80% 80
90% 82
95% 84
98% 296
99% 301
100% 301 (longest request)
Dopo aver eseguito il nostro primo test, sarà facile riconoscere lo schema di utilizzo di questo comando che è il seguente:
# ab [options .....] URL
dove,
ab - Comando Apache Bench
options - flag per attività particolari che vogliamo eseguire
URL - URL del percorso che vogliamo testare
Comprensione dei valori di output
Dobbiamo comprendere le diverse metriche per comprendere i vari valori di output restituiti da ab. Ecco l'elenco:
Server Software - È il nome del server web restituito nell'intestazione HTTP del primo ritorno riuscito.
Server Hostname - È l'indirizzo DNS o IP fornito sulla riga di comando.
Server Port- È la porta a cui ab si connette. Se non viene fornita alcuna porta sulla riga di comando, il valore predefinito sarà 80 per http e 443 per https.
SSL/TLS Protocol- Questo è il parametro del protocollo negoziato tra il client e il server. Questo verrà stampato solo se viene utilizzato SSL.
Document Path - Questo è l'URI della richiesta analizzato dalla stringa della riga di comando.
Document Length- È la dimensione in byte del primo documento restituito con successo. Se la lunghezza del documento cambia durante il test, la risposta è considerata un errore.
Concurrency Level - Questo è il numero di client simultanei (equivalente ai browser Web) utilizzati durante il test.
Time Taken for Tests - Questo è il tempo impiegato dal momento in cui viene creata la prima connessione socket al momento in cui viene ricevuta l'ultima risposta.
Complete Requests - Il numero di risposte ricevute con successo.
Failed Requests- Il numero di richieste considerate non riuscite. Se il numero è maggiore di zero, verrà stampata un'altra riga che mostra il numero di richieste non riuscite a causa di connessione, lettura, lunghezza del contenuto errata o eccezioni.
Total Transferred- Il numero totale di byte ricevuti dal server. Questo numero è essenzialmente il numero di byte inviati in rete.
HTML Transferred- Il numero totale di byte del documento ricevuti dal server. Questo numero esclude i byte ricevuti nelle intestazioni HTTP
Requests per second- Questo è il numero di richieste al secondo. Questo valore è il risultato della divisione del numero di richieste per il tempo totale impiegato.
Time per request- Il tempo medio impiegato per richiesta. Il primo valore viene calcolato con la formula concurrency * timesaken * 1000 / done mentre il secondo valore viene calcolato con la formula timeaken * 1000 / done
Transfer rate - La velocità di trasferimento calcolata dalla formula totalread / 1024 / timeaken.
Analisi rapida dell'output del test di carico
Dopo aver appreso le intestazioni dei valori di output dal comando ab, proviamo ad analizzare e comprendere i valori di output per il nostro test iniziale -
L'organizzazione Apache utilizza il proprio software per server Web: Apache (versione 2.4.7)
Il server è in ascolto sulla porta 443 a causa di https. Se fosse stato http, sarebbe stato 80 (predefinito).
I dati totali trasferiti sono 58769 byte per 100 richieste.
Test completato in 1.004 secondi. Non ci sono richieste fallite.
Richieste al secondo - 99,56. Questo è considerato un numero abbastanza buono.
Tempo per richiesta: 100,444 ms (per 10 richieste simultanee). Quindi, in tutte le richieste, è 100,444 ms / 10 = 10,044 ms.
Velocità di trasferimento - 1338,39 [Kbyte / sec] ricevuti.
Nelle statistiche sui tempi di connessione è possibile osservare che molte richieste hanno dovuto attendere alcuni secondi. Ciò potrebbe essere dovuto al server Web Apache che mette le richieste in coda di attesa.
Nel nostro primo test, avevamo testato un'applicazione (ad esempio, www.apache.org) ospitata su un server diverso. Nella parte successiva del tutorial, testeremo le nostre applicazioni web di esempio ospitate sullo stesso server da cui eseguiremo gli ab test. Questo è per la facilità di apprendimento e scopo dimostrativo. Idealmente, il nodo host e il nodo di test dovrebbero essere diversi per una misurazione accurata.
Per imparare meglio ab, dovresti confrontare e osservare come variano i valori di output per i diversi casi mentre andiamo avanti in questo tutorial.
Tracciare l'output di Apache Bench
Qui tracceremo il risultato rilevante per vedere quanto tempo impiega il server all'aumentare del numero di richieste. Per questo, aggiungeremo il file-g opzione nel comando precedente seguita dal nome del file (qui out.data) in cui verranno salvati i dati di output ab -
$ ab -n 100 -c 10 -g out.data https://www.apache.org/
Vediamo ora il file out.data prima di creare una trama -
$ less out.data
Output
starttime seconds ctime dtime ttime wait
Tue May 30 12:11:37 2017 1496160697 40 38 77 13
Tue May 30 12:11:37 2017 1496160697 42 38 79 13
Tue May 30 12:11:37 2017 1496160697 41 38 80 13
...
Vediamo ora di comprendere le intestazioni di colonna nel file out.data file -
starttime - Questa è la data e l'ora in cui è iniziata la chiamata.
seconds - Come starttime ma nel formato timestamp Unix (date -d @ 1496160697 restituisce l'output starttime).
ctime - Questo è il tempo di connessione.
dtime - Questo è il tempo di elaborazione.
ttime - Questo è il tempo totale (è la somma di ctime e dtime, matematicamente ttime = ctime + dtime).
wait - Questo è il tempo di attesa.
Per una visualizzazione pittorica di come questi più elementi sono correlati tra loro, dai un'occhiata alla seguente immagine:
Se stiamo lavorando su terminale o dove la grafica non è disponibile, gnuplotè un'ottima opzione. Lo capiremo rapidamente eseguendo i seguenti passaggi.
Installiamo e lanciamo gnuplot -
$ sudo apt-get install gnuplot
$ gnuplot
Output
G N U P L O T
Version 4.6 patchlevel 6 last modified September 2014
Build System: Linux x86_64
Copyright (C) 1986-1993, 1998, 2004, 2007-2014
Thomas Williams, Colin Kelley and many others
gnuplot home: http://www.gnuplot.info
faq, bugs, etc: type "help FAQ"
immediate help: type "help" (plot window: hit 'h')
Terminal type set to 'qt'
gnuplot>
Dato che stiamo lavorando sul terminale e supponiamo che la grafica non sia disponibile, possiamo scegliere il terminale stupido che fornirà l'output in ASCII sul terminale stesso. Questo ci aiuta a farci un'idea di come appare la nostra trama con questo rapido strumento. Prepariamo ora il terminale per il grafico ASCII.
gnuplot> set terminal dumb
Output
Terminal type set to 'dumb'
Options are 'feed size 79, 24'
Poiché il nostro terminale gnuplot è ora pronto per il grafico ASCII, tracciamo i dati dal file out.data file -
gnuplot> plot "out.data" using 9 w l
Output
1400 ++-----+------+-----+------+------+------+------+-----+------+-----++
+ + + + + + +"out.data" using 9 ****** +
| |
1200 ++ ********************************************
| ******************* |
1000 ++ * ++
| * |
| * |
800 ++ * ++
| * |
| * |
600 ++ * ++
| * |
| * |
400 ++ * ++
| * |
200 ++ * ++
| * |
+**** + + + + + + + + + +
0 ++-----+------+-----+------+------+------+------+-----+------+-----++
0 10 20 30 40 50 60 70 80 90 100
Abbiamo tracciato il ttime, tempo totale (in ms) dalla colonna 9, rispetto al numero di richieste. Possiamo notare che per le richieste dieci iniziali, il tempo totale è stato di quasi 100 ms, per i prossimi 30 richieste (da 10 ° a 40 ° ), ha aumentato a 1100 ms, e così via. La trama deve essere diversa a seconda del tuoout.data.
Nel capitolo precedente, abbiamo compreso l'uso di base di Apache Bench per testare un sito Web di terze parti. In questa sezione, utilizzeremo questo strumento per testare un'applicazione web sul nostro server. Per mantenere il tutorial autonomo per quanto possibile, abbiamo scelto di installare un'applicazione python a scopo dimostrativo; puoi scegliere qualsiasi altra lingua come PHP o Ruby a seconda del tuo livello di esperienza.
Installazione di Python
Generalmente, Python è installato per impostazione predefinita sui server Linux.
Installazione di Bottle Framework e creazione di un'applicazione semplice
Bottle è un micro-framework scritto in python per la creazione di applicazioni web e pip è un gestore di pacchetti python. Digita il seguente comando nel terminale per installare Bottle -
$ sudo apt-get install python-pip
$ sudo pip install bottle
Creiamo ora una piccola applicazione Bottle. Per questo, crea una directory e spostati al suo interno -
$ mkdir webapp
$ cd webapp
Creeremo un nuovo script python, app.py, all'interno della directory webapp -
$ vim app.py
Ora scrivi il seguente codice nel file app.py -
from bottle import Bottle, run
app = Bottle()
@app.route('/')
@app.route('/hello')
def hello():
return "Hello World!"
run(app, host = 'localhost', port = 8080)
Dopo aver aggiunto le righe precedenti, salva e chiudi il file. Dopo aver salvato il file, possiamo eseguire lo script python per avviare l'applicazione -
$ python app.py
Output
Bottle v0.12.7 server starting up (using WSGIRefServer())...
Listening on http://localhost:8080/
Hit Ctrl-C to quit.
Questo output mostra che la nostra applicazione è in esecuzione sulla macchina locale dell'host http://localhost e ascolto sul porto 8080.
Controlliamo se la nostra app risponde correttamente alle richieste HTTP. Poiché questo terminale non può ricevere alcun input senza uscire dal servizio dell'applicazione Bottle, dobbiamo accedere al nostro VPS con un altro terminale. Dopo aver effettuato l'accesso al VPS con un altro terminale, è possibile accedere alla propria applicazione digitando il seguente codice nel nuovo terminale.
$ lynx http://localhost:8080/
Lynx è un browser a riga di comando e di solito è installato di default in varie distribuzioni Linux come Debian e Ubuntu. Se vedi il seguente output, significa che la tua app funziona correttamente.
Output
Se vedi l'output sopra, significa che la nostra applicazione è attiva e pronta per il test.
Test dell'applicazione con Developmental Web Server
Si noti che c'è un bug in ab e non è possibile testare l'applicazione sul localhost. Quindi cambieremo l'host da localhost a 127.0.0.1 nel file app.py. Quindi il file cambierà nel seguente:
from bottle import Bottle, run
app = Bottle()
@app.route('/')
@app.route('/hello')
def hello():
return "Hello World!"
run(app, host = '127.0.0.1', port = 8080)
Proviamo ora la nostra app digitando il seguente comando sullo stesso terminale su cui è stato eseguito il comando lynx -
$ ab -n 100 -c 10 http://127.0.0.1:8080/hello
Output
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient).....done
Server Software: WSGIServer/0.1
Server Hostname: 127.0.0.1
Server Port: 8080
Document Path: /hello
Document Length: 12 bytes
Concurrency Level: 10
Time taken for tests: 0.203 seconds
Complete requests: 100
Failed requests: 0
Total transferred: 16500 bytes
HTML transferred: 1200 bytes
Requests per second: 493.78 [#/sec] (mean)
Time per request: 20.252 [ms] (mean)
Time per request: 2.025 [ms] (mean, across all concurrent requests)
Transfer rate: 79.56 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.1 0 0
Processing: 1 6 28.2 2 202
Waiting: 1 6 28.2 2 202
Total: 1 6 28.2 2 202
Percentage of the requests served within a certain time (ms)
50% 2
66% 2
75% 2
80% 2
90% 2
95% 2
98% 202
99% 202
100% 202 (longest request)
Mentre l'uscita sul primo terminale sarà (100 volte) come segue:
...
127.0.0.1 - - [10/Jun/2017 04:30:26] "GET /hello HTTP/1.0" 200 12
127.0.0.1 - - [10/Jun/2017 04:30:26] "GET /hello HTTP/1.0" 200 12
127.0.0.1 - - [10/Jun/2017 04:30:26] "GET /hello HTTP/1.0" 200 12
...
È possibile osservare come sono cambiati i vari valori del risultato ab rispetto al test iniziale.
Test dell'applicazione con un server Web multi-thread
Nei precedenti test di ab, abbiamo utilizzato il server web predefinito in bundle nel framework Bottle.
Ora cambieremo il server web predefinito a thread singolo con uno multi-thread. Pertanto, installiamo una libreria di server web multi-thread comecherrypy o gunicorne dì a Bottle di usarlo. Abbiamo scelto gunicorn per lo scopo dimostrativo qui (puoi sceglierne anche un altro) -
$ sudo apt-get install gunicorn
E modifica il file, ovvero cambia dal server web predefinito a gunicorn -
...
run(server = 'gunicorn'...)
...
Proviamo l'app nel secondo terminale.
$ ab -n 100 -c 10 http://127.0.0.1:8080/hello
Output
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient).....done
Server Software: gunicorn/19.0.0
Server Hostname: 127.0.0.1
Server Port: 8080
Document Path: /hello
Document Length: 12 bytes
Concurrency Level: 10
Time taken for tests: 0.031 seconds
Complete requests: 100
Failed requests: 0
Total transferred: 17200 bytes
HTML transferred: 1200 bytes
Requests per second: 3252.77 [#/sec] (mean)
Time per request: 3.074 [ms] (mean)
Time per request: 0.307 [ms] (mean, across all concurrent requests)
Transfer rate: 546.36 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 0.9 0 4
Processing: 1 2 0.7 3 4
Waiting: 0 2 0.8 2 3
Total: 2 3 0.6 3 5
WARNING: The median and mean for the initial connection time are not within a normal
deviation These results are probably not that reliable.
WARNING: The median and mean for the processing time are not within a normal deviation
These results are probably not that reliable.
Percentage of the requests served within a certain time (ms)
50% 3
66% 3
75% 3
80% 3
90% 4
95% 5
98% 5
99% 5
100% 5 (longest request)
Osserva come le richieste al secondo sono aumentate da 493 a 3252. Significa che gunicorn è adatto come server di produzione per app python.
In questo capitolo impareremo come testare più URL contemporaneamente. Per questo, dovremo modificare il nostro file dell'applicazione, app.py per includere due URL:
from bottle import Bottle, run
app = Bottle()
@app.route('/')
@app.route('/hello1')
def hello():
return "Hello World! It is first URL."
@app.route('/hello2')
def hello():
return "Hello World! It is second URL."
run(app,server = 'gunicorn',host = '127.0.0.1', port = 8080)
Creazione di un semplice script di shell
Puoi farlo creando uno script di shell, con più chiamate ab. Crea un file test.sh e aggiungi le seguenti righe:
ab -n 100 -c 10 http://127.0.0.1:8080/hello1
ab -n 100 -c 10 http://127.0.0.1:8080/hello2
Dopo aver aggiunto le righe precedenti, salva e chiudi il file. Rendi il file eseguibile -
chmod u+x test.sh
Eseguiamo ora lo script -
./test.sh
Per evitare ripetizioni e scopo di chiarezza, mostreremo solo il pertinente dell'output ab, indicando con punti quale parte è stata omessa, come di seguito.
Produzione
.
.
.
Document Path: /hello1
Document Length: 732 bytes
Concurrency Level: 10
Time taken for tests: 0.040 seconds
Complete requests: 100
Failed requests: 0
Non-2xx responses: 100
Total transferred: 90000 bytes
HTML transferred: 73200 bytes
Requests per second: 2496.13 [#/sec] (mean)
Time per request: 4.006 [ms] (mean)
Time per request: 0.401 [ms] (mean, across all concurrent requests)
Transfer rate: 2193.87 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.8 0 3
Processing: 1 3 1.0 4 5
Waiting: 0 3 1.2 4 4
Total: 1 4 0.6 4 5
WARNING: The median and mean for the processing time are not within a normal deviation
These results are probably not that reliable.
.
.
.
Script della shell per salvare l'output di Apache Bench in un file
È possibile salvare l'output di Apache Bench su file creando uno script di shell, con più chiamate ab. Alla fine di ogni riga, posizionare un&;questo fa eseguire il comando in background e consente al comando successivo di avviare la sua esecuzione. Dovrai anche reindirizzare l'output a un file per ogni URL usando <nomefile>. Ad esempio, il nostro file test.sh sarà simile al seguente dopo la modifica:
$ ab -n 100 -c 10 http://127.0.0.1:8080/hello1 > test1.txt &
$ ab -n 100 -c 10 http://127.0.0.1:8080/hello2 > test2.txt &
Qui, test1.txt e test2.txt sono i file per salvare i dati di output.
Puoi controllare che lo script sopra abbia creato due file, test1.txt e test2.txt che contiene l'output ab per i rispettivi URL -
$ ls -l
Produzione
...
-rw-r--r-- 1 root root 5225 May 30 12:11 out.data
-rwxr--r-- 1 root root 118 Jun 10 12:24 test.sh
-rw-r--r-- 1 root root 1291 Jun 10 12:31 test1.txt
-rwxr--r-- 1 root root 91 Jun 10 13:22 test2.sh
-rw-r--r-- 1 root root 1291 Jun 10 12:31 test2.txt
...
Situazione di attenzione
Durante l'utilizzo di ab, dovresti essere attento al test fallito senza preavviso. Ad esempio, se controlli un URL sbagliato, potresti ottenere qualcosa di simile al seguente (abbiamo deliberatamente cambiato la porta qui).
$ ab -l -r -n 100 -c 10 -k -H "Accept-Encoding: gzip, deflate" http://127.0.0.1:805/
Produzione
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient).....done
Server Software:
Server Hostname: 127.0.0.1
Server Port: 805
Document Path: /
Document Length: Variable
Concurrency Level: 10
Time taken for tests: 0.002 seconds
Complete requests: 100
Failed requests: 150
(Connect: 0, Receive: 100, Length: 0, Exceptions: 50)
Keep-Alive requests: 0
Total transferred: 0 bytes
HTML transferred: 0 bytes
Requests per second: 44984.26 [#/sec] (mean)
Time per request: 0.222 [ms] (mean)
Time per request: 0.022 [ms] (mean, across all concurrent requests)
Transfer rate: 0.00 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 0
Processing: 0 0 0.2 0 0
Waiting: 0 0 0.0 0 0
Total: 0 0 0.2 0 0
Percentage of the requests served within a certain time (ms)
50% 0
66% 0
75% 0
80% 0
90% 0
95% 0
98% 0
99% 0
100% 0 (longest request)
In questo capitolo capiremo la preparazione richiesta per testare le pagine dinamiche. Una pagina Web dinamica lato server è una pagina Web la cui costruzione è controllata da un server delle applicazioni che elabora script lato server. Il banco di apache può solo testare il carico della pagina web dinamica lato server.
Livello di concorrenza e numero totale di richieste
Il livello di concorrenza deve essere inferiore al numero totale di richieste.
$ ab -l -r -n 30 -c 80 -k -H "Accept-Encoding: gzip, deflate" http://127.0.0.1:8000/
Output
ab: Cannot use concurrency level greater than total number of requests
Usage: ab [options] [http[s]://]hostname[:port]/path
Uso delle bandiere
In questa sezione descriveremo l'uso di alcuni flag importanti con il comando ab. Useremo termini, opzioni e flag in modo intercambiabile.
Verbose -v
L'opzione dettagliata può essere utilizzata per analizzare ed eseguire il debug se esiste un numero multiplo di richieste non riuscite. Un'indicazione comune di fallimento del test di carico è che il test termina molto velocemente e fornisce un buon numero di richieste al secondo. Ma sarà un benchmark sbagliato. Per identificare il successo o il fallimento, puoi utilizzare-v 2opzione che scaricherà il corpo e l'intestazione di ciascuna risposta nell'output del terminale. Il comando seguente descrive un caso d'uso:
$ ab -n 1 -v 2 http://www.generic-example-URL.com/
Output
LOG: header received:
HTTP/1.0 200 OK
…
Content-Length: 2548687
Ovviamente, se stai testando risposte variabili o restituendo codici HTTP non 200 in caso di errore, dovresti semplicemente ignorare il controllo della lunghezza con il -lopzione. Presto vedremo HTTP non 200 quando lanceremo un'applicazione web2py nei capitoli successivi.
Keep-alive -k
Quando il client invia la richiesta HTTP, la connessione viene effettuata al server, il server invia la risposta e la connessione viene chiusa dopo aver inviato la richiesta. Questo ciclo continua con ogni richiesta. Tuttavia, con l'impostazione keep-alive (nota anche come connessioni persistenti), il client mantiene aperta una connessione TCP sottostante per facilitare più richieste e risposte; questo elimina il lento e costoso tempo di inizializzazione della connessione che altrimenti sarebbe presente.
Lunghezza documento variabile -l
Se la pagina Web è di lunghezza variabile, è necessario utilizzare l'opzione -l. Apache Bench non segnala errori se la lunghezza delle risposte non è costante. Questo può essere utile per le pagine dinamiche.
Uso dell'opzione -r
Come forzare ab a non uscire alla ricezione di errori? Dovresti usare l'opzione-r. Senza questa opzione, il test potrebbe interrompersi non appena una richiesta colpisce l'errore del socket. Tuttavia, con questa opzione, gli errori verranno riportati nell'intestazione degli errori non riusciti, ma il test continuerà fino alla fine.
Utilizzo dell'opzione -H
Questa opzione viene utilizzata per aggiungere una riga di intestazione arbitraria. L'argomento ha in genere la forma di una riga di intestazione valida, contenente una coppia campo-valore separata da due punti (ad esempio, "Accept-Encoding: zip / zop; 8bit").
Utilizzo dell'opzione -C
Nella sezione seguente, impareremo in dettaglio come utilizzare le opzioni di cui sopra in combinazione con l'opzione per utilizzare il valore del cookie, ovvero il -Copzione. L'opzione -C ha in genere la forma di un filename = valuepaio. Questo campo può essere ripetuto.
Utilizzo del cookie di sessione con Apache Bench
Per capire come utilizzare il cookie con Apache Bench, abbiamo bisogno di una pagina web che tenti di impostare un cookie. Un ottimo esempio è l'applicazione web2py che è un framework web Python.
Installazione di web2py
Installeremo rapidamente un'altra app python web2py. Puoi leggere di più su come usarlo su Panoramica di Web2py Framework .
Python è generalmente installato per impostazione predefinita sui server Ubuntu e Debian. Pertanto, un requisito è già soddisfatto per eseguire correttamente web2py.
Tuttavia, dobbiamo installare il pacchetto unzip per estrarre i file sorgente di web2py dal file zip che andremo a scaricare -
$ sudo apt-get update
$ sudo apt-get install unzip
Prendiamo il framework web2py dal sito web del progetto. Lo scaricheremo nella nostra cartella home -
$cd ~
$ wget http://www.web2py.com/examples/static/web2py_src.zip
Ora possiamo decomprimere il file che abbiamo appena scaricato e spostarci all'interno -
$ unzip web2py_src.zip
$ cd web2py
Per eseguire web2py, non è necessario installarlo. Una volta che sei all'interno della directory web2py, puoi eseguirlo digitando il seguente comando:
$python web2py.py
Se tutto è andato a buon fine, vedrai il seguente output in cui ti verrà chiesto di scegliere una password per l'interfaccia utente amministrativa -
web2py Web Framework
Created by Massimo Di Pierro, Copyright 2007-2017
Version 2.14.6-stable+timestamp.2016.05.10.00.21.47
Database drivers available: sqlite3, imaplib, pymysql, pg8000
WARNING:web2py:GUI not available because Tk library is not installed
choose a password:
please visit:
http://127.0.0.1:8000/
use "kill -SIGTERM 23904" to shutdown the web2py server
Tuttavia, è necessario essere consapevoli del fatto che l'interfaccia web avviata è accessibile solo sulla macchina locale.
Dall'output, puoi capire che per fermare il server web, dovrai digitare "CTRL-C" nel terminale istantaneo. Per fermare invece il server web2py sull'altro terminale relativo allo stesso VPS, si può inserire il comando kill -SIGTERM <PID>, dove <PID> è l'ID di processo del server web2py, che in questo caso è 23904.
Cookie di sessione da web2py
Se una pagina è accessibile solo da un utente loggato, non direttamente accessibile dalla pagina di login, in tal caso puoi utilizzare il -Cbandiera. Questo flag definisce un cookie per il comando ab. Ma devi ottenere il valore del cookie dell'identificatore di sessione da una sessione valida. Come ottenerlo? Vari tutorial online ti guideranno verso gli strumenti di sviluppo del browser Chrome (o Mozilla). Ma nel nostro caso di test, poiché l'applicazione è disponibile solo sulla riga di comando, utilizzeremo il browser lynx per ottenere il valore.
Otteniamo prima il valore del cookie di una sessione. Apri un altro terminale e digita il seguente comando:
$ lynx http://127.0.0.1:8000/
In risposta al comando precedente, lynx chiederà il tuo permesso per accettare il cookie dal server web2py come mostrato nell'immagine sotto.
Annotare il valore del cookie prima di digitare yper accettare il cookie. Ora il terminale sarà simile alla seguente immagine: sito web sul terminale!
Dopo aver ottenuto il valore del cookie, eseguiremo ora il test ab. Per questo, dovremo aprire il terzo terminale (vedi l'immagine sotto) -
Ora, usiamo il flag -C nel terzo terminale -
$ ab -n 100 -c 10 -C session_name = 127.0.0.1-643dad04-3c34 http://127.0.0.1:8000/
Produzione
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient).....done
Server Software: Rocket
Server Hostname: 127.0.0.1
Server Port: 8000
Document Path: /
Document Length: 66 bytes
Concurrency Level: 10
Time taken for tests: 0.051 seconds
Complete requests: 100
Failed requests: 0
Non-2xx responses: 100
Total transferred: 27700 bytes
HTML transferred: 6600 bytes
Requests per second: 1968.12 [#/sec] (mean)
Time per request: 5.081 [ms] (mean)
Time per request: 0.508 [ms] (mean, across all concurrent requests)
Transfer rate: 532.39 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 1 2 0.9 2 4
Processing: 0 3 0.9 3 5
Waiting: 0 2 1.1 2 4
Total: 4 5 0.7 5 7
Percentage of the requests served within a certain time (ms)
50% 5
66% 5
75% 5
80% 6
90% 6
95% 6
98% 7
99% 7
100% 7 (longest request)
Dall'output sopra, notiamo diversi punti. Innanzitutto, web2py utilizza il server web Rocket . Notiamo anche che stiamo ottenendo "Risposte non 2xx" oltre ai titoli discussi in precedenza nell'output. In generale, il protocollo Http risponde a una richiesta utilizzando un codice di risposta, e qualsiasi cosa all'interno dell'intervallo 200 significa "ok", e il resto corrisponde a qualche problema. Ad esempio, i 400 sono errori relativi alle risorse come 404 File non trovato. 500 corrispondono a errori del server. Nel nostro caso istantaneo, non ci sono errori da nessuna parte tranne quando stiamo usando l'opzione -C. Può essere soppresso usando l'opzione -l come già descritto.
Controllo della pagina di amministrazione
In questa sezione capiremo come controllare la pagina di amministrazione. A scopo di confronto, testiamo un altro URL dell'applicazione web2py -
$ ab -n 100 -c 10 session_name = 127.0.0.1-643dad04-3c34 http://127.0.0.1:8000/admin
Produzione
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient).....done
Server Software: Rocket
Server Hostname: 127.0.0.1
Server Port: 8000
Document Path: /admin
Document Length: 8840 bytes
Concurrency Level: 10
Time taken for tests: 2.077 seconds
Complete requests: 100
Failed requests: 0
Total transferred: 926700 bytes
HTML transferred: 884000 bytes
Requests per second: 48.14 [#/sec] (mean)
Time per request: 207.749 [ms] (mean)
Time per request: 20.775 [ms] (mean, across all concurrent requests)
Transfer rate: 435.61 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 3.2 0 12
Processing: 62 204 52.2 199 400
Waiting: 61 203 52.0 199 400
Total: 62 205 54.3 199 411
Percentage of the requests served within a certain time (ms)
50% 199
66% 211
75% 220
80% 226
90% 264
95% 349
98% 381
99% 411
100% 411 (longest request)
Si segnalano in particolare le rispettive statistiche nella sezione “Tempi di connessione” e “Percentuale delle richieste servite…” di http://127.0.0.1:8000/ e http://127.0.0.1:8000/admin. C'è un'enorme differenza.
Utilizzo dell'opzione Timelimit
In generale, l'opzione Timelimit è complicata. Cerchiamo di capirlo dal manuale di ab , che è abbastanza esplicativo -
-t timelimit
Maximum number of seconds to spend for benchmarking. This implies a -n 50000 internally.
Use this to benchmark the server within a fixed total amount of time.
Per default there is no timelimit.
Facciamo un test con questa opzione. Prenderemo nota delle nostre osservazioni dopo aver esaminato l'output -
$ ab -n 100 -c 10 -t 60 http://127.0.0.1:8000/
Produzione
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient)
Completed 5000 requests
Completed 10000 requests
Completed 15000 requests
Completed 20000 requests
Completed 25000 requests
Completed 30000 requests
Completed 35000 requests
Completed 40000 requests
Completed 45000 requests
Completed 50000 requests
Finished 50000 requests
Server Software: Rocket
Server Hostname: 127.0.0.1
Server Port: 8000
Document Path: /
Document Length: 66 bytes
Concurrency Level: 10
Time taken for tests: 22.547 seconds
Complete requests: 50000
Failed requests: 0
Non-2xx responses: 50000
Total transferred: 13850000 bytes
HTML transferred: 3300000 bytes
Requests per second: 2217.61 [#/sec] (mean)
Time per request: 4.509 [ms] (mean)
Time per request: 0.451 [ms] (mean, across all concurrent requests)
Transfer rate: 599.88 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 2 0.8 2 8
Processing: 0 2 3.2 2 218
Waiting: 0 2 3.2 2 218
Total: 2 4 3.1 4 220
Percentage of the requests served within a certain time (ms)
50% 4
66% 4
75% 4
80% 5
90% 5
95% 5
98% 7
99% 8
100% 220 (longest request)
Si noti che l'output mostra che questa opzione sovrascrive il numero di richieste specificato da -nopzione e continua fino a 50.000 richieste. Tuttavia, poiché le richieste sono state gestite molto rapidamente, ab è terminato non appena è stato raggiunto il punteggio di 50k - entro 22 secondi (vedere il titolo Tempo impiegato per i test) nel caso in questione.
Puoi testare lo stesso comando sostituendo http://127.0.0.1:8000/ con http://127.0.0.1:8000/admin (supponendo che sia la nostra applicazione web2py) o un sito Web di terze parti come https://www.apache.org/, nota la differenza nelle statistiche.
Elenco di controllo prima di eseguire il test di carico
Ci sono alcuni controlli che ti aiuteranno a eseguire con successo il test e a misurare accuratamente le prestazioni. Considerare le seguenti condizioni prima di eseguire il test di carico:
Assicurati che non venga caricato alcun modulo Python aggiuntivo.
Per evitare l'esaurimento della porta TCP / IP, è necessario attendere 2-3 minuti prima di passare a un altro test ab.
Assicurati che il numero di connessioni simultanee sia inferiore a Apache Worker Threads.
È necessario riavviare il server prima di eseguire un altro test, se Apache o python si arresta in modo anomalo.
In questo capitolo descriveremo le varie combinazioni di -n e -c con i flag importanti per aumentare gradualmente il carico sul tuo webserver.
Dovresti concentrarti principalmente su come cambiano le seguenti metriche all'aumentare del carico:
- Richieste al secondo
- Tempi di connessione (ms)
- Percentuale delle richieste servite entro un certo tempo (ms)
Dovresti anche notare il valore di soglia quando il server inizia a bloccarsi e inizi a ricevere richieste non riuscite.
1 utente simultaneo che esegue 100 pagine visitate
Facciamo 100 caricamenti di pagine sequenziali da parte di un singolo utente -
$ ab -l -r -n 100 -c 1 -k -H "Accept-Encoding: gzip, deflate" http://127.0.0.1:8000/
Produzione
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient).....done
Server Software: Rocket
Server Hostname: 127.0.0.1
Server Port: 8000
Document Path: /
Document Length: Variable
Concurrency Level: 1
Time taken for tests: 0.045 seconds
Complete requests: 100
Failed requests: 0
Non-2xx responses: 100
Keep-Alive requests: 0
Total transferred: 27700 bytes
HTML transferred: 6600 bytes
Requests per second: 2206.24 [#/sec] (mean)
Time per request: 0.453 [ms] (mean)
Time per request: 0.453 [ms] (mean, across all concurrent requests)
Transfer rate: 596.80 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 0
Processing: 0 0 0.0 0 0
Waiting: 0 0 0.0 0 0
Total: 0 0 0.0 0 1
Percentage of the requests served within a certain time (ms)
50% 0
66% 0
75% 0
80% 0
90% 1
95% 1
98% 1
99% 1
100% 1 (longest request)
5 utenti simultanei ciascuno che esegue 10 visite di pagina
Questo caso corrisponde a un picco di carico su un sito Web che ottiene circa 50.000+ visite al mese.
$ ab -l -r -n 10 -c 5 -k -H "Accept-Encoding: gzip, deflate" http://127.0.0.1:8000/
Nei seguenti output successivi, ometteremo l'intestazione comune per motivi di chiarezza.
Produzione
...
Requests per second: 2009.24 [#/sec] (mean)
Time per request: 2.488 [ms] (mean)
Time per request: 0.498 [ms] (mean, across all concurrent requests)
Transfer rate: 543.52 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 0.5 1 2
Processing: 0 1 0.5 1 2
Waiting: 0 1 0.5 1 1
Total: 2 2 0.4 3 3
ERROR: The median and mean for the total time are more than twice the standard
deviation apart. These results are NOT reliable.
Percentage of the requests served within a certain time (ms)
50% 3
66% 3
75% 3
80% 3
90% 3
95% 3
98% 3
99% 3
100% 3 (longest request)
10 utenti simultanei ciascuno che esegue 10 visite di pagina
Questo test corrisponde a 100 caricamenti di pagine da parte di 10 diversi utenti simultanei, ogni utente esegue 10 caricamenti di pagine sequenziali.
$ ab -r -n 10 -c 10 -k -H "Accept-Encoding: gzip, deflate" http://127.0.0.1:8000/
Produzione
...
Requests per second: 2225.68 [#/sec] (mean)
Time per request: 4.493 [ms] (mean)
Time per request: 0.449 [ms] (mean, across all concurrent requests)
Transfer rate: 602.07 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 1 2 0.7 2 3
Processing: 0 2 1.0 2 3
Waiting: 0 1 1.0 2 3
Total: 4 4 0.3 4 4
WARNING: The median and mean for the waiting time are not within a normal deviation
These results are probably not that reliable.
Percentage of the requests served within a certain time (ms)
50% 4
66% 4
75% 4
80% 4
90% 4
95% 4
98% 4
99% 4
100% 4 (longest request)
20 utenti simultanei ciascuno facendo 20 visite di pagina
Questo test corrisponde a 400 caricamenti di pagine da parte di 20 diversi utenti simultanei, ogni utente esegue 20 caricamenti di pagine sequenziali.
$ ab -r -n 20 -c 20 -k -H “Accept-Encoding: gzip, deflate” http://127.0.0.1:8000/
Produzione
...
Requests per second: 1619.96 [#/sec] (mean)
Time per request: 12.346 [ms] (mean)
Time per request: 0.617 [ms] (mean, across all concurrent requests)
Transfer rate: 438.21 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 2 6 2.3 6 10
Processing: 1 5 2.9 5 10
Waiting: 0 5 2.9 5 9
Total: 10 11 0.6 11 12
Percentage of the requests served within a certain time (ms)
50% 11
66% 11
75% 12
80% 12
90% 12
95% 12
98% 12
99% 12
100% 12 (longest request)
30 utenti simultanei ciascuno facendo 30 visite alla pagina
Questo test corrisponde a 900 caricamenti di pagine da parte di 30 diversi utenti simultanei, ogni utente esegue 30 caricamenti di pagine sequenziali.
$ ab -r -n 30 -c 30 -k -H "Accept-Encoding: gzip, deflate" http://127.0.0.1:8000/
Produzione
...
Requests per second: 2283.45 [#/sec] (mean)
Time per request: 13.138 [ms] (mean)
Time per request: 0.438 [ms] (mean, across all concurrent requests)
Transfer rate: 617.69 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 2 6 2.7 6 11
Processing: 1 6 3.1 6 11
Waiting: 0 5 3.2 5 10
Total: 11 12 0.5 12 13
Percentage of the requests served within a certain time (ms)
50% 12
66% 12
75% 12
80% 12
90% 13
95% 13
98% 13
99% 13
100% 13 (longest request)
Ora abbiamo imparato come aumentare gradualmente il carico sul sito web e testarne le prestazioni.
In questo capitolo confronteremo gli output con e senza flag. Vediamo come l'uso di flag appropriati può aumentare le prestazioni della tua applicazione web. Prima di ciò, dobbiamo capire come se la tua applicazione è semplice, potresti non notare la differenza. Come nel caso della nostra semplice applicazione, con flag e senza flag. Quindi eseguiremo lo stesso test conhttps://www.apache.org/ URL e vedi la differenza.
Testare la nostra applicazione senza flag
In questa sezione capiremo come testare la nostra applicazione senza flag.
$ ab -n 100 -c 10 http://127.0.0.1:8000/
Produzione
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient).....done
Server Software: Rocket
Server Hostname: 127.0.0.1
Server Port: 8000
Document Path: /
Document Length: Variable
Concurrency Level: 10
Time taken for tests: 0.244 seconds
Complete requests: 100
Failed requests: 0
Non-2xx responses: 100
Keep-Alive requests: 0
Total transferred: 27700 bytes
HTML transferred: 6600 bytes
Requests per second: 2208.77 [#/sec] (mean)
Time per request: 4.527 [ms] (mean)
Time per request: 0.453 [ms] (mean, across all concurrent requests)
Transfer rate: 597.49 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 1 2 0.7 2 3
Processing: 0 2 0.7 2 4
Waiting: 0 2 1.0 2 3
Total: 4 4 0.3 4 5
Percentage of the requests served within a certain time (ms)
50% 4
66% 4
75% 5
80% 5
90% 5
95% 5
98% 5
99% 5
100% 5 (longest request)
Testare la nostra applicazione con i flag
In questa sezione capiremo come testare la nostra applicazione con i flag.
$ ab -l -r -n 100 -c 10 -k -H "Accept-Encoding: gzip, deflate" http://127.0.0.1:8000/
Produzione
...
Requests per second: 2277.07 [#/sec] (mean)
Time per request: 4.392 [ms] (mean)
Time per request: 0.439 [ms] (mean, across all concurrent requests)
Transfer rate: 615.97 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 1 2 0.7 2 3
Processing: 0 2 0.7 2 4
Waiting: 0 2 1.0 2 3
Total: 4 4 0.2 4 5
Percentage of the requests served within a certain time (ms)
50% 4
66% 4
75% 4
80% 4
90% 5
95% 5
98% 5
99% 5
100% 5 (longest request)
Possiamo semplicemente notare che non c'è molta differenza tra le statistiche di output.
Test del sito Web dell'organizzazione Apache senza flag
Vediamo ora come testare il sito Web dell'organizzazione Apache senza flag.
$ ab -n 100 -c 10 http://www.apache.org/
Produzione
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking www.apache.org (be patient).....done
Server Software: Apache/2.4.7
Server Hostname: www.apache.org
Server Port: 80
Document Path: /
Document Length: 58433 bytes
Concurrency Level: 10
Time taken for tests: 1.498 seconds
Complete requests: 100
Failed requests: 0
Total transferred: 5877500 bytes
HTML transferred: 5843300 bytes
Requests per second: 66.74 [#/sec] (mean)
Time per request: 149.840 [ms] (mean)
Time per request: 14.984 [ms] (mean, across all concurrent requests)
Transfer rate: 3830.58 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 12 110 295.2 12 1012
Processing: 37 38 0.5 38 39
Waiting: 12 13 0.3 13 15
Total: 49 147 295.4 50 1051
Percentage of the requests served within a certain time (ms)
50% 50
66% 50
75% 50
80% 50
90% 816
95% 1050
98% 1051
99% 1051
100% 1051 (longest request)
Test del sito Web dell'organizzazione Apache con i flag
Proviamo ora a testare il sito Web dell'organizzazione Apache con i flag.
$ ab -l -r -n 100 -c 10 -k -H "Accept-Encoding: gzip, deflate" http://www.apache.org/
Produzione
...
Document Length: Variable
Concurrency Level: 10
Time taken for tests: 0.357 seconds
Complete requests: 100
Failed requests: 0
Keep-Alive requests: 100
Total transferred: 1358510 bytes
HTML transferred: 1317700 bytes
Requests per second: 280.28 [#/sec] (mean)
Time per request: 35.678 [ms] (mean)
Time per request: 3.568 [ms] (mean, across all concurrent requests)
Transfer rate: 3718.41 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 3.7 0 12
Processing: 14 17 21.3 15 227
Waiting: 14 17 21.3 14 227
Total: 14 18 21.5 15 227
Percentage of the requests served within a certain time (ms)
50% 15
66% 15
75% 15
80% 15
90% 27
95% 28
98% 29
99% 227
100% 227 (longest request)
Puoi semplicemente notare come la richiesta al secondo è aumentata con l'uso dei flag. Nella fattispecie, è particolarmente dovuto all'uso di-H "Accept-Encoding: gzip, deflate perché questo flag indica al server Apache di servire le richieste in gzipped formato.
Considerando i risultati di Apache Bench
Alcuni punti importanti devono essere considerati quando si tratta dei risultati di Apache Bench. Questo ci aiuterà a progettare la nostra strategia generale per rimuovere i colli di bottiglia nella nostra applicazione e migliorarne le prestazioni.
Abbiamo bisogno di richieste al secondo. Questo ci dà un'idea di come funziona bene la configurazione del nostro server web; maggiore è il numero, migliori sono le prestazioni. Poi vengono i tempi di connessione (ms) e la percentuale delle richieste servite. Potrebbe essere necessario modificare le impostazioni del server Web per modificare queste metriche in base alle prestazioni desiderate.
Verificare se sono presenti errori nei log degli errori del server Web di Apache o utilizzato o nei log (generali). Man mano che aumenterai il tuo carico, le cose inizieranno a soffocare: inizieranno a sorgere problemi di memoria. Molti script Python inizieranno a bloccarsi se non sono scritti pensando alla concorrenza.
Hai bisogno di scoprire qual è il valore critico di concorrenza al di sopra del quale il tuo server web va in crash e / o va in timeout? Normalmente questo dovrebbe accadere a un livello di concorrenza abbastanza alto. Se questo valore è basso, qualcosa non va ed è necessario regolare queste impostazioni più in basso / più in alto.
Conclusione
In questo tutorial abbiamo appreso come utilizzare Apache Bench per testare il carico di qualsiasi sito web o applicazione web. Apache Bench può essere uno strumento molto prezioso per determinare come migliorare la configurazione del server di applicazioni Web, ridurre i colli di bottiglia e aumentare le prestazioni. Ora che hai familiarità con l'utilizzo di base di Apache Bench, puoi iniziare creando nuovi piani di test per misurare le prestazioni delle tue applicazioni in vari scenari.