Preparazione per il test delle pagine dinamiche

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 finisce 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 una richiesta HTTP, la connessione viene stabilita 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 scaricheremo -

$ 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 web server, 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 segnala 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 ea misurare accuratamente le prestazioni. Considerare le seguenti condizioni prima di eseguire il test di carico:

  • Assicurati che nessun modulo Python aggiuntivo sia caricato.

  • 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.