Benchmarking mit ab und autobench

Vor kurzem habe ich ein wenig zum Thema Benchmarking geschrieben. Dieses Thema ist für viele Entwickler ein Buch mit sieben Siegeln. Deswegen hier ein paar erklärende Worte, wie man auf einfache Art und Weise eine aussagekräftige Messung inklusive vorzeigbarem Graphen für den eigenen Webserver generieren kann.

Das Problem

Niemand weiß so recht, wie schnell ein Webserver eigentlich ist und wie viele Anfragen er verarbeiten kann, bis er zusammenbricht. Abwarten, bis der GAU eintritt, ist die schlechteste Variante, dem Problem zu begegnen. Besser ist es, einen Benchmark durchzuführen, um die Skalierfähigkeit eines Servers einschätzen zu können. Antwortet des Server zu langsam auf Anfragen, bleiben eventuell Besucher fern und es wäre an der Zeit, über Lastverteilung oder einen dickeren Server nachzudenken.

Der einfachste Ansatz: ab

Jeder Apache-Webserver bringt von Hause aus ab mit. ab funktioniert denkbar einfach (Eingabe im Terminal/Kommandozeile/Shell):

ab -c 20 -n 100 http://127.0.0.1/

In diesem Fall werden 20 gleichzeitige Benutzer (concurrent requests) mit 100 Anfragen (number of requests) an den Webserver unter der Adresse 127.0.0.1 geschickt1. In diesem Fall wird die index.html meines lokalen Webservers ausgeliefert, was in der Regel schnell ablaufen dürfte. Die Ausgabe von ab bestätigt dies:

<br></br>  
This is ApacheBench, Version 2.3 <$Revision: 655654 $><br></br>  
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/<br></br>  
Licensed to The Apache Software Foundation, http://www.apache.org/  

Benchmarking 127.0.0.1 (be patient)…..done

Server Software:Apache/2.2.9
Server Hostname:127.0.0.1
Server Port:80
Document Path:/
Document Length:1456 bytes
Concurrency Level:20
Time taken for tests:0.081 seconds
Complete requests:100
Failed requests:0
Write errors:0
Total transferred:186000 bytes
HTML transferred:145600 bytes
Requests per second:1240.46 [#/sec] (mean)
Time per request:16.123 [ms] (mean)
Time per request:0.806 [ms] (mean, across all concurrent requests)
Transfer rate:2253.19 [Kbytes/sec] received
Connection Times (ms)

minmean[+/-sd]medianmax
Connect:000.301
Processing:10154.91329
Waiting:3145.11329
Total:10155.01329
Percentage of the requests served within a certain time (ms)
50% 13
66% 14
75% 15
80% 19
90% 25
95% 27
98% 29
99% 29
100% 29 (longest request)

Diesen Test kann man nun mehrfach durchführen und den Wert für -c jeweils anpassen. Von -c 10 bis -c 150 oder noch weiter. Aus den erhaltenen Werten läßt sich nun ein Diagramm in Excel oder OOo.

Wenn es dem Apachen zu viele Anfragen werden, schaltet er einfach ab (Connection reset by peer):

<br></br>  
Macintosh:~ stephan$ ab -c 150 -n 2000 http://127.0.0.1/<br></br>  
This is ApacheBench, Version 2.3 <$Revision: 655654 $><br></br>  
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/<br></br>  
Licensed to The Apache Software Foundation, http://www.apache.org/  

Benchmarking 127.0.0.1 (be patient)
Completed 200 requests
Completed 400 requests
Completed 600 requests
Completed 800 requests
Completed 1000 requests
Completed 1200 requests
Completed 1400 requests
Completed 1600 requests
aprsocketrecv: Connection reset by peer (54)
Total of 1688 requests completed

Kurzer Exkurs in die Konfiguration des Apache

Warum wurde die Verbindung zurückgesetzt? Die Lösung findet sich (für den Apache 2.x unter Mac OS X 10.5.6) in der Datei /etc/apache2/extra/httpd-mpm.conf

StartServers 1 MinSpareServers 1 MaxSpareServers 10 MaxClients 150 MaxRequestsPerChild 0

Wenn der Wert für -c über dem Wert von MaxClients gesetzt wird, reagiert der Webserver per Definition nicht mehr auf diese Benutzer. Allerdings ist die Anzahl der Anfragen pro Client hier nicht begrenzt. Eine genaue Auseinandersetzung mit den Einstellungsmöglichkeiten und der Performanceoptimierung von Webservern ist jedoch nicht das Thema hier, sondern das Messen der Performance.

Komfortables Benchmarking mit autobench

Auf dem Mac kann man autobench unter anderem mit den MacPorts installieren:

$ sudo port install autobench

Zur Erzeugung von Graphen ist außerdem das Programm gnuplot notwendig:

$ sudo port install gnuplot

Ich vermute, dass die Installation von gnuplot nicht ganz korrekt verläuft, da bench2graph (in einem späteren Arbeitsschritt) unter OS X nicht funktioniert.

Die Funktionsweise von autobench

autobench ist ein Perl-Skript, welches httperf mit ansteigender Anzahl an Abfragen startet und die wesentlichen Ergebnisse in einer Komma- (csv) oder Tabulator-separierten (tsv) Datei abspeichert. Diese Datei wiederum kann als Grundlage für Graphen genutzt werden.

Das Prinzip ist also ähnlich wie bei einer Testreihe mit ab. Allerdings sieht man bereits an der Konfiguration, dass httperf bzw. autobench dem Benutzer etwas mehr abverlangt.

Konfiguration von autobench

.autobench.conf im Heimverzeichnis des Anwenders beinhaltet die Standardkonfiguration von autobench. Auf den ersten Blick zeigt sich ein deutlicher Unterschied zur Arbeit mit ab: Es können zwei Server konfiguriert (host1 und host2). Da hier jedoch nur ein Server getestet werden soll, konfiguriere ich nur host1. Die wesentlichen und in unserem Beispiel relevanten Einstellungen sehen wie folgt aus:

host1 = localhost uri1 = / port1 = 80 lowrate = 10 highrate = 200 ratestep = 10 numconn = 5000 numcall = 10 timeout = 5 outputfmt = tsv

autobench schickt also Anfragen an den Server localhost (127.0.0.1) auf Port 80 an die dort hinterlegte Startseite (in diesem Fall index.html). Begonnen wird mit 10 gleichzeitigen Verbindungen (low_rate) und 10 Anfragen (num_call) bei insgesamt 5000 Verbindungen für den einzelnen Testlauf (num_con). Pro Testlauf wird nun die Anzahl gleichzeitiger Verbindungen um 10 (rate_step) erhöht, bis sie 200 (high_rate) erreicht. Wenn der Webserver nicht innerhalb von 5 Sekunden (timeout) antwortet, so wird dies von autobench als Fehler gewertet. Das Ergebnis wird im tsv-Format (output_fmt) ausgegeben.

Ein Testlauf mit autobench

Es gibt prinzipiell zwei Möglichkeiten, autobench aufzurufen. Einerseits so, dass die Ergebnisse dargestellt werden und andererseits so, dass die Ergebnisse in einer Datei protokolliert werden. Gibt man auf der Kommandozeile keine expliziten Parameter an, dann werden die Einstellungen der .autobench.conf genutzt.

$ autobench —single_host —file bench.tsv

Mit —single_host wird autobench angewiesen, nur die Einstellungen für host1 zu verwenden, der Parameter —file zeigt an, dass die Ergebisse in die Datei bench.tsv geschrieben werden sollen.

Je nach Konfiguration heißt es jetzt ein bißchen warten. Wer gerne sehen möchte, was passiert, kann entweder auf der Konsole zusehen oder eine zweite Shell öffnen und dem Logfile beim Wachsen zusehen:

$ tail -f bench.tsv

Graphen mit bench2graph

Im Normalfall ist der nächste Schritt nach dem eigentlichen Test die Aufbereitung der Ergebnisse. Unter Mac OS X ist es mir leider nicht gelungen, mit gnuplot und bench2graph die tsv-Datei zu verarbeiten. Es kam immer dieselbe Fehlermeldung:

<br></br>  
$bench2graph bench2.tsv result.ps<br></br>
-n Enter the title : <br></br>
Der Titel meines Benchmarking Graphen  

-n plot
^
“gnuplot.cmd”, line 8: invalid command

Da ich kein Experte für gnuplot bin, habe ich einen einfachen (Um-)Weg gewählt (unter Ubuntu funktionierte die Erstellung des Graphen einwandfrei).

1 Natürlich muss der Wert für -c immer kleiner als der von -n sein, sonst gäbe es Benutzer, die keine Anfragen stellen würden und der Befehl in sich wird sinnlos.

Author image
Blogging since 2003 about life, tech, yoga. Passionate about the details and eager to know more. Systems theory meets empathy.
Bochum. Germany.
top