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.