Apache Benchmark Test mit der ab.exe, Apache Stress Test

Wenn Sie wissen möchten was ein Apache Webserver leisten kann, testen Sie es mit dem Apache Benchmark Tool ab.exe. Man muss also nicht so lange warten, bis der Server an seine Leistunggrenze kommt und stresst ihn schon einmal vorher, um vorzusorgen.

Hier wird ein fehlerhaftes Verhalten des Apache beschrieben, das man mit dem AB Tool und dem Wireshark dokumentieren konnte.

Möglicherweise belasteen den Apache die Client Zugriffe so stark, dass es zu Leistungseinschränkungen kommt. Vielleicht liegt die Ursache wo anders….

Unsere Aufgabe ist es jedoch zuerst, das Verhalten zu dokumentieren.

Wir verwenden ab.exe, ein Werkzeug, das während der Apache Installation mit installiert wird.

Download Benchmark Test für Apache

Wir testen den Server mit

  1. einer einfachen HTML-Datei
  2. und einer einfachen PHP-Datei

Dazu brauchen einen Rechner, wo diese ab.exe installiert ist.  Wir achten darauf, dass die Verbindung zwischen dem Testrechner und dem Apache Server sehr gut ist, mit iperf kann man die Verbindung zwischen diesen Rechnern besser vorher überprüfen.

Wir erstellen nun die benötigten Dateien zum Testen oder laden sie hier herunter.

Eine einfache HTML Datei (download test.html)

Eine einfache HTML Datei
Stresse mich !!!
Stresse mich !!!
Stresse mich !!!

und ein PHP File (download test.php)

Es ist sinnvoll die Kommandos in einer CMD Datei unterzubringen, um Änderungen leicht vornehmen zu können.

Apache Benchmark Dateien

PHP info

Nun starten wir die Abfragen von der Kommandozeile aus dem Verzeichnis, wo sich die ab.exe befindet :

#
# Starte 250 Anfragen, 15 gleichzeitig
ab.exe -n 250 -c 15 http://www.mydomain.de/stress.html

# Starte 250 Anfragen, 15 gleichzeitig
ab.exe -n 250 -c 15  http://www.mydomain.de/stress.php
#

Das Ergebnis der mit der stress.html sieht schon überhaupt nicht gut aus :

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

Benchmarking erika01.intern.zgt.de (be patient).....done

Server Software:        Apache/2.2.0
Server Hostname:        www.mydomain.de
Server Port:            80

Document Path:          /stress.html
Document Length:        145 bytes

Concurrency Level:      10
Time taken for tests:   95.861 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      42800 bytes
HTML transferred:       14500 bytes
Requests per second:    1.04 [#/sec] (mean)
Time per request:       9586.122 [ms] (mean)
Time per request:       958.612 [ms] (mean, across all concurrent requests)
Transfer rate:          0.44 [Kbytes/sec] received

Connection Times (ms)
min  mean[+/-sd] median   max
Connect:        0   29 292.2      0    2922
Processing:  8000 9351 917.8   9188   13844
Waiting:     8000 9351 917.8   9188   13844
Total:       8000 9380 1010.2   9188   13844

Percentage of the requests served within a certain time (ms)
50%   9188
66%   9500
75%   9969
80%  10094
90%  10735
95%  10922
98%  13844
99%  13844
100%  13844 (longest request)

Wir sehen, dass 50 % der Anfragen in 9188 ms ausgeliefert wurden. Das muss einen Grund haben. Dazu überprüfen wir den Datenstrom zwischen dem Rechner mit der ab.exe und dem Apache Server mit dem Wireshark Tool.

Wireshark stellt und die Kommunikation zwischen dem Benchmark Tool und dem Apache Server gut dar. Uns interessiert, woher diese 9-11 Sekunden Wartezeit kommen. Da die ab.exe 25 Anfragen gleichzeitig gestartet hatte, müssen wir und alle Pakete, die zur einer GET Anfrage zugehören anschauen. Dazu machen wir einen Rechtsklick auf ein GET Paket und wählen “Follow TCP Stream” aus.

 

Wireshark erstellt sofort einen Filter und wenden diesen auf alle Daten an. Als Ergebnis sehen wir diesen einen GET Versuch, den das Benchmark Tool gestartet hatte. Beim näheren Betrachten fällt auf, dass zwischen der GET Anfrage und der HTML Antwort genau 11 Sekunden liegen.

Den Tracefile kann man hier downloaden .

Nun muss man sich fragen, woher dies kommt. Das ist jedoch eine andere Baustelle.
In diesem Fall war es eine Einschränkung der gleichzeitigen Sessions im Apache :=(.  Nach der Korrektur nach oben lief der Apache wieder flott und bremste die Benutzer nicht mehr aus.