Apache Bench @ OpenShift
Cosa vedrai
Apache Bench
Apache Bench (abbreviato in ab) è uno strumento per eseguire test di carico e benchmarking per applicazioni che usano il protocollo HTTP.
Può essere eseguito da riga di comando ed è molto semplice da usare: un output del test di carico può essere ottenuto in un solo minuto.
Poiché non richiede troppa familiarità con i concetti di test di carico e prestazioni, è adatto a principianti e utenti intermedi. Per utilizzare questo strumento, non è richiesta alcuna configurazione complessa e, anzi, viene installato automaticamente con il server web Apache, oppure può essere installato separatamente come utility Apache.
Richiede infatti appena 128MB di RAM, e non ci sono requisiti minimi sul sistema operativo o sulla dimensione del disco che dev’essere allocata.
Come funziona
Per poterla usare all’interno di un ambiente come OpenShift, è sufficiente creare un controller che sfrutti l’immagine httpd, ossia l’immagine ufficiale del server Apache. Nel catalogo di default di OpenShift è infatti presente sia un template che una builder image di Apache HTTP Server che avrà già ab installato.
Selezioniamo il template e procediamo con una nuova istanza, lasciando il repository di esempio di GitHub:
Il pod sarà avviato nel giro di qualche secondo e mostrerà dei log simili a questi:
A questo punto, possiamo cominciare con i test di carico sul nostro sito: facciamo un piccolo test e proviamo ad eseguire Apache Bench con 100 request inviate al sito di Apache, di cui 10 request concorrenti per volta.
Per farlo, eseguiamo il seguente comando da terminale:
ab -n 100 -c 10 https://www.apache.org/
>>>
This is ApacheBench, Version 2.3 <$Revision: 1826891 $>
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
Server Hostname: www.apache.org
Server Port: 443
SSL/TLS Protocol: TLSv1.2,ECDHE-RSA-AES128-GCM-SHA256,2048,128
TLS Server Name: www.apache.org
Document Path: /
Document Length: 75751 bytes
Concurrency Level: 10
Time taken for tests: 0.138 seconds
Complete requests: 100
Failed requests: 0
Total transferred: 7626140 bytes
HTML transferred: 7575100 bytes
Requests per second: 723.43 [#/sec] (mean)
Time per request: 13.823 [ms] (mean)
Time per request: 1.382 [ms] (mean, across all concurrent requests)
Transfer rate: 53876.89 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 4 8 6.2 6 58
Processing: 2 5 4.6 3 36
Waiting: 1 4 4.6 2 35
Total: 6 13 8.4 10 66
Percentage of the requests served within a certain time (ms)
50% 10
66% 12
75% 14
80% 17
90% 20
95% 23
98% 57
99% 66
100% 66 (longest request)
Cosa ottieni
Cerchiamo di capire un po’ più nel dettaglio l’output:
- L’organizzazione Apache utilizza il proprio software server web Apache
- Il server è in ascolto sulla porta 443 a causa di https. Se fosse stato http, sarebbe stato 80 (impostazione predefinita)
- I dati totali trasferiti sono 75751 byte per 100 richieste
- Test completato in 0.138 secondi. Non ci sono richieste fallite
- Richieste al secondo - 723.43. Questo è considerato un numero abbastanza buono
- Tempo per richiesta − 13.823 ms (per 10 richieste simultanee). Quindi, per ogni richiesta, è 13.823 ms/10 = 1.3823 ms
- Velocità di trasferimento − 53876.89 Kbyte/sec ricevuti
- Nelle statistiche sui tempi di connessione, puoi osservare che molte richieste hanno dovuto attendere pochi secondi. Ciò potrebbe essere dovuto al server Web Apache che mette le richieste in coda di attesa.
Il time taken for tests rappresenta il tempo impiegato per i test, ossia il tempo impiegato dal momento in cui viene creata la prima connessione al server al momento in cui viene ricevuta l’ultima risposta.
Per maggiori dettagli
Per riuscire a visualizzare più informazioni, come quanto tempo è necessario per completare una richiesta, possiamo sfruttare il parametro -g, che permette di scrivere su un file ciò che avviene all’interno del test di carico request-by-request:
ab -n 100 -c 10 -g out.data https://www.apache.org/
>>>
This is ApacheBench, Version 2.3 <$Revision: 1826891 $>
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
Server Hostname: www.apache.org
Server Port: 443
SSL/TLS Protocol: TLSv1.2,ECDHE-RSA-AES128-GCM-SHA256,2048,128
TLS Server Name: www.apache.org
sh-4.2$ cat out.data
starttime seconds ctime dtime ttime wait
Mon Dec 19 16:30:51 2022 1671467451 4 1 6 1
Mon Dec 19 16:30:51 2022 1671467451 4 3 7 2
Mon Dec 19 16:30:51 2022 1671467451 5 2 7 1
Mon Dec 19 16:30:51 2022 1671467451 5 2 7 1
...
starttime rappresenta la data di inizio del test, mentre seconds è la stessa data, ma nel formato Unix in millisecondi; ctime è il tempo di connessione, dtime il tempo di processamento e ttime il risultato totale dei primi due. wait rappresenta infine il tempo di attesa tra l’invio della richiesta e l’arrivo del primo byte dal server.
Per avere un’idea un po’ più chiara di come si “intrecciano” questi tempi, è sufficiente dare un’occhiata a questo schema:
E se volessi testare anche più URL contemporaneamente? Puoi farlo creando uno script di shell, con più chiamate ab. Alla fine di ogni riga posiziona un &: questo fa sì che il comando venga eseguito in background e consenta l’avvio dell’esecuzione del comando successivo. Dovrai anche reindirizzare l’output a un file per ogni URL utilizzando > nome file
Ad esempio:
#!/bin/sh
ab -n 100 -c 10 http://mywebsite.com/firstpage.html > test1.txt &
ab -n 100 -c 10 http://mywebsite.com/secondpage.html > test2.txt &
Conclusioni
Quanto visto finora è un accenno molto veloce di come sfruttare Apache Bench per testare un’applicazione: ci sono moltissime opzioni disponibili che possiamo utilizzare per personalizzare i test di carico, anche se è chiaro che si tratta di un ambiente limitato in termini di funzionalità rispetto a strumenti come Apache JMeter!
Usage: ab [options] [http[s]://]hostname[:port]/path
Options are:
-n requests Number of requests to perform
-c concurrency Number of multiple requests to make
-t timelimit Seconds to max. wait for responses
-b windowsize Size of TCP send/receive buffer, in bytes
-p postfile File containing data to POST. Remember also to set -T
-T content-type Content-type header for POSTing, eg.
'application/x-www-form-urlencoded'
Default is 'text/plain'
-v verbosity How much troubleshooting info to print
-w Print out results in HTML tables
-i Use HEAD instead of GET
-x attributes String to insert as table attributes
-y attributes String to insert as tr attributes
-z attributes String to insert as td or th attributes
-C attribute Add cookie, eg. 'Apache=1234. (repeatable)
-H attribute Add Arbitrary header line, eg. 'Accept-Encoding: gzip'
Inserted after all normal header lines. (repeatable)
-A attribute Add Basic WWW Authentication, the attributes
are a colon separated username and password.
-P attribute Add Basic Proxy Authentication, the attributes
are a colon separated username and password.
-X proxy:port Proxyserver and port number to use
-V Print version number and exit
-k Use HTTP KeepAlive feature
-d Do not show percentiles served table.
-S Do not show confidence estimators and warnings.
-g filename Output collected data to gnuplot format file.
-e filename Output CSV file with percentages served
-r Don't exit on socket receive errors.
-h Display usage information (this message)
-Z ciphersuite Specify SSL/TLS cipher suite (See openssl ciphers)
-f protocol Specify SSL/TLS protocol (SSL2, SSL3, TLS1, or ALL)
