Apache Bench - Kurzanleitung

Leistungstests haben sich als entscheidend für den Erfolg eines Unternehmens erwiesen. Ein Standort mit schlechter Leistung ist nicht nur mit finanziellen Verlusten konfrontiert, sondern kann zuweilen auch rechtliche Auswirkungen haben.

Niemand möchte sich mit einer langsamen, unzuverlässigen Website in wichtigen Online-Interaktionen wie Einkauf, Online-Testdurchführung, Rechnungszahlung usw. abfinden. Da das Internet so weit verbreitet ist, ist die Auswahl an Alternativen immens. Es ist einfacher, Kunden zu verlieren als zu gewinnen, und die Leistung ist ein entscheidender Faktor für das Spiel.

Benötigen Sie ein Lasttest-Tool

Wenn wir verstehen können, was für ein Lasttestwerkzeug erforderlich ist, gibt es uns den Grund und die Motivation, es zu verwenden. Einige berühmte Geschäftsstandorte haben ernsthafte Ausfallzeiten erlitten, wenn sie eine große Anzahl von Besuchern haben. E-Commerce-Websites investieren stark in Werbekampagnen, nicht jedoch in Lasttests. Daher stellen sie keine optimale Systemleistung sicher, wenn dieses Marketing Datenverkehr einbringt.

Ein weiteres bekanntes Beispiel für das Ignorieren von Lasttests ist das "Fehler beim Herstellen einer Verbindung" auf WordPress-Websites. Daher ist es eine gute Idee, eine Website oder Anwendung vor ihrer Bereitstellung in der Produktion zu testen. Es ist schön, schnell ein Best-Case-Szenario für ein Projekt zu erstellen, bevor später detailliertere Tests durchgeführt werden.

Was ist Apache Bench?

Apache Bench (ab) ist ein Tool der Apache-Organisation zum Benchmarking eines HTTP-Webservers (Hypertext Transfer Protocol). Obwohl es die Leistung des Apache-Webservers messen soll, kann es auch zum Testen jedes anderen Webservers verwendet werden, der gleich gut ist. Mit diesem Tool können Sie schnell feststellen, wie viele Anforderungen Ihr Webserver pro Sekunde verarbeiten kann.

Eigenschaften von Apache Bench

Lassen Sie uns die wichtigen Funktionen und Einschränkungen von Apache Bench sehen. Die Funktionen und Einschränkungen sind unten aufgeführt -

  • Als Open-Source-Software ist sie frei verfügbar.

  • Es ist ein einfaches Befehlszeilen-Computerprogramm.

  • Es ist ein plattformunabhängiges Tool. Dies bedeutet, dass es unter Linux / Unix oder auf Windows-Servern gleich gut aufgerufen werden kann.

  • Es kann Last- und Leistungstests nur für Webserver durchführen - HTTP oder HTTPS.

  • Es ist nicht erweiterbar.

Apache Bench verwendet unabhängig von der Parallelitätsstufe (angegeben durch das Flag -c) nur einen Betriebssystem-Thread. Daher kann beim Benchmarking von Servern mit hoher Kapazität eine einzelne Instanz von Apache Bench selbst ein Engpass sein. Um die Ziel-URL vollständig zu sättigen, ist es besser, zusätzliche Instanzen von Apache Bench parallel zu verwenden, wenn Ihr Server über mehrere Prozessorkerne verfügt.

Vorsicht

Sie müssen sich bewusst sein, dass es in der Apache Bench keine Anweisung gibt, die Parallelität in bestimmten Intervallen zu erhöhen, während Tests ausgeführt werden. Daher entspricht das Ausführen von Lasttests mit ab einem Denial-of-Service-Angriff (DOS). Es wird empfohlen, dass Sie Ihren VPS-Dienstanbieter informieren und die vorherige Genehmigung einholen, wenn Sie über einen längeren Zeitraum Schwerlasttests durchführen möchten. Sie weisen Ihnen ein geeignetes Zeitintervall zu oder verschieben Ihren Knoten für die Lasttestaufgabe.

Zweitens besteht die Möglichkeit, dass Ihre öffentliche VPS-IP-Adresse von der Website der dritten Person blockiert wird, wenn Sie die Website einer dritten Person kontinuierlich und über einen längeren Zeitraum testen, nur um Apache Bench von Ihrem VPS zu lernen (der zum Testknoten wird) permanent. In diesem Fall können Sie keine Verbindung zu dieser Website mit derselben IP-Adresse herstellen. Wenn Sie jedoch in Zukunft wirklich eine Verbindung zur Website herstellen möchten, besteht die einzige Lösung darin, mit dem Systemadministrator der Zielwebsite zu sprechen oder mithilfe Ihres VPS-Dienstanbieters eine neue Instanz des Servers mit einer anderen IP-Adresse zu erstellen.

Nachdem ich Sie gewarnt habe, kann ich Ihnen versichern, dass alle Tests in diesem Lernprogramm sicher genug sind und nicht den von Systemadministratoren allgemein als "Systemmissbrauch" bezeichneten Praktiken entsprechen.

In diesem Kapitel erfahren Sie, wie Sie Ihre Umgebung für Apache Bench auf Ihrem VPS einrichten.

System Anforderungen

  • Memory - 128 MB

  • Disk Space - Keine Mindestanforderung

  • Operating System - Keine Mindestanforderung

Apache Bench installieren

Apache Bench ist eine eigenständige Anwendung und hat keine Abhängigkeiten von der Installation des Apache-Webservers. Das Folgende ist ein zweistufiger Prozess zum Installieren von Apache Bench.

Step 1 - Aktualisieren Sie die Paketdatenbank.

# apt-get update

Bitte beachten Sie, dass das Symbol # vor einem Terminalbefehl bedeutet, dass der Root-Benutzer diesen Befehl ausgibt.

Step 2 - Installieren Sie das Apache2-Utils-Paket, um Zugriff auf Apache Bench zu erhalten.

# apt-get install apache2-utils

Apache Bench ist jetzt installiert. Wenn Sie eine Webanwendung testen möchten, die auf demselben VPS gehostet wird, reicht es aus, nur den Apache-Webserver zu installieren.

# apt-get install apache2

Als Apache-Dienstprogramm wird Apache Bench bei der Installation des Apache-Webservers automatisch installiert.

Überprüfen der Apache Bench-Installation

Lassen Sie uns nun sehen, wie Sie die Apache Bench-Installation überprüfen. Der folgende Code hilft bei der Überprüfung der Installation -

# 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/

Wenn Sie die obige Terminalausgabe sehen, bedeutet dies, dass Sie Apache Bench erfolgreich installiert haben.

Erstellen eines privilegierten Sudo-Benutzers

Unter Sicherheitsgesichtspunkten wird es für Systemadministratoren als bewährte Methode angesehen, einen Sudo-Benutzer zu erstellen, anstatt als Root zu arbeiten. Wir werden einen Testbenutzer namens test erstellen, um -

# useradd -m -d /home/test -g sudo test

Lassen Sie uns das Passwort für den neuen Benutzer festlegen -

# passwd test

Das System fordert Sie zur Eingabe eines neuen Kennworts für den Benutzertest auf. Sie können ein einfaches Kennwort eingeben, da wir nur testen und nicht auf dem Produktionsserver bereitstellen. Normalerweise werden Sie vom Befehl sudo aufgefordert, das sudo-Benutzerkennwort einzugeben. Es wird empfohlen, kein kompliziertes Kennwort zu verwenden, da der Vorgang umständlich wird.

Output

Enter new UNIX password:
Retype new UNIX password:   
passwd: password updated successfully

Testen der Apache.org-Website

In diesem Abschnitt testen wir die Apache.org-Website. Wechseln wir zunächst zum sudo user test -

# su test

Zunächst werden wir die Website der Apache-Organisation testen. https://www.apache.org/. Wir werden zuerst den Befehl ausführen und dann die Ausgabe verstehen -

$ ab -n 100 -c 10 https://www.apache.org/

Hier -nist die Anzahl der Anforderungen, die für die Benchmarking-Sitzung ausgeführt werden müssen. Standardmäßig wird nur eine einzelne Anforderung ausgeführt, was normalerweise zu nicht repräsentativen Benchmarking-Ergebnissen führt.

Und -cist die Parallelität und gibt die Anzahl mehrerer Anforderungen an, die gleichzeitig ausgeführt werden sollen. Standard ist jeweils eine Anforderung.

In diesem Test sendet Apache Bench 100 Anfragen mit Parallelität 10 an den Apache-Organisationsserver.

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)

Nachdem Sie unseren ersten Test ausgeführt haben, ist das Verwendungsmuster für diesen Befehl wie folgt leicht zu erkennen:

# ab [options .....]  URL

wo,

  • ab - Apache Bench Befehl

  • options - Flags für eine bestimmte Aufgabe, die wir ausführen möchten

  • URL - Pfad-URL, die wir testen möchten

Grundlegendes zu den Ausgabewerten

Wir müssen die verschiedenen Metriken verstehen, um die verschiedenen von ab zurückgegebenen Ausgabewerte zu verstehen. Hier geht die Liste -

  • Server Software - Dies ist der Name des Webservers, der im HTTP-Header der ersten erfolgreichen Rückgabe zurückgegeben wird.

  • Server Hostname - Dies ist die in der Befehlszeile angegebene DNS- oder IP-Adresse.

  • Server Port- Dies ist der Port, an den ab angeschlossen ist. Wenn in der Befehlszeile kein Port angegeben ist, wird standardmäßig 80 für http und 443 für https verwendet.

  • SSL/TLS Protocol- Dies ist der Protokollparameter, der zwischen Client und Server ausgehandelt wird. Dies wird nur gedruckt, wenn SSL verwendet wird.

  • Document Path - Dies ist der Anforderungs-URI, der aus der Befehlszeilenzeichenfolge analysiert wird.

  • Document Length- Dies ist die Größe des ersten erfolgreich zurückgegebenen Dokuments in Byte. Wenn sich die Dokumentlänge während des Tests ändert, wird die Antwort als Fehler betrachtet.

  • Concurrency Level - Dies ist die Anzahl der gleichzeitigen Clients (entspricht Webbrowsern), die während des Tests verwendet werden.

  • Time Taken for Tests - Dies ist die Zeit, die vom Herstellen der ersten Socket-Verbindung bis zum Empfang der letzten Antwort benötigt wird.

  • Complete Requests - Die Anzahl der erfolgreichen Antworten.

  • Failed Requests- Die Anzahl der Anfragen, die als fehlgeschlagen angesehen wurden. Wenn die Anzahl größer als Null ist, wird eine weitere Zeile gedruckt, in der die Anzahl der Anforderungen angegeben ist, die aufgrund von Verbindung, Lesen, falscher Inhaltslänge oder Ausnahmen fehlgeschlagen sind.

  • Total Transferred- Die Gesamtzahl der vom Server empfangenen Bytes. Diese Anzahl ist im Wesentlichen die Anzahl der über die Leitung gesendeten Bytes.

  • HTML Transferred- Die Gesamtzahl der vom Server empfangenen Dokumentbytes. Diese Zahl schließt in HTTP-Headern empfangene Bytes aus

  • Requests per second- Dies ist die Anzahl der Anfragen pro Sekunde. Dieser Wert ergibt sich aus der Division der Anzahl der Anforderungen durch die Gesamtzeit.

  • Time per request- Die durchschnittliche Zeit pro Anfrage. Der erste Wert wird mit der Formel Parallelität * Zeitplan * 1000 / erledigt berechnet, während der zweite Wert mit der Formel Zeitplan * 1000 / erledigt berechnet wird

  • Transfer rate - Die Übertragungsrate, berechnet nach der Formel totalread / 1024 / timetaken.

Schnelle Analyse der Lasttestleistung

Nachdem wir die Überschriften der Ausgabewerte aus dem Befehl ab kennengelernt haben, versuchen wir, die Ausgabewerte für unseren ersten Test zu analysieren und zu verstehen.

  • Die Apache-Organisation verwendet ihre eigene Webserver-Software - Apache (Version 2.4.7).

  • Der Server überwacht Port 443 aufgrund von https. Wäre es http gewesen, wäre es 80 gewesen (Standard).

  • Die insgesamt übertragenen Daten betragen 58769 Byte für 100 Anforderungen.

  • Test in 1.004 Sekunden abgeschlossen. Es gibt keine fehlgeschlagenen Anforderungen.

  • Anfragen pro Sekunde - 99,56. Dies wird als ziemlich gute Zahl angesehen.

  • Zeit pro Anfrage - 100,444 ms (für 10 gleichzeitige Anfragen). Über alle Anforderungen hinweg beträgt sie also 100,444 ms / 10 = 10,044 ms.

  • Übertragungsrate - 1338,39 [KB / s] empfangen.

  • In der Verbindungszeitstatistik können Sie feststellen, dass viele Anforderungen einige Sekunden warten mussten. Dies kann daran liegen, dass der Apache-Webserver Anforderungen in die Warteschlange stellt.

In unserem ersten Test hatten wir eine Anwendung (dh www.apache.org) getestet, die auf einem anderen Server gehostet wurde. Im späteren Teil des Tutorials werden wir unsere Beispiel-Webanwendungen testen, die auf demselben Server gehostet werden, von dem aus wir die ab-Tests ausführen werden. Dies dient der Erleichterung des Lernens und der Demonstration. Idealerweise sollten sich der Hostknoten und der Testknoten für eine genaue Messung unterscheiden.

Um ab besser zu lernen, sollten Sie vergleichen und beobachten, wie sich die Ausgabewerte für verschiedene Fälle ändern, während wir in diesem Lernprogramm fortfahren.

Zeichnen der Ausgabe von Apache Bench

Hier werden wir das relevante Ergebnis darstellen, um zu sehen, wie viel Zeit der Server benötigt, wenn die Anzahl der Anforderungen zunimmt. Dafür werden wir die hinzufügen-g Option im vorherigen Befehl, gefolgt vom Dateinamen (hier out.data), in dem die ab-Ausgabedaten gespeichert werden -

$ ab -n 100 -c 10 -g out.data https://www.apache.org/

Lassen Sie uns jetzt die sehen out.data bevor wir eine Handlung erstellen -

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

Lassen Sie uns nun die Spaltenüberschriften in der out.data Datei -

  • starttime - Dies ist das Datum und die Uhrzeit, zu der der Anruf gestartet wurde.

  • seconds - Wie Startzeit, jedoch im Unix-Zeitstempelformat (Datum -d @ 1496160697 gibt die Startzeitausgabe zurück).

  • ctime - Dies ist die Verbindungszeit.

  • dtime - Dies ist die Bearbeitungszeit.

  • ttime - Dies ist die Gesamtzeit (es ist die Summe von ctime und dtime, mathematisch ttime = ctime + dtime).

  • wait - Dies ist die Wartezeit.

Schauen Sie sich das folgende Bild an, um eine bildliche Darstellung der Beziehung zwischen diesen mehreren Elementen zu erhalten:

Wenn wir über ein Terminal arbeiten oder wenn keine Grafiken verfügbar sind, gnuplotist eine gute Option. Wir werden es schnell verstehen, indem wir die folgenden Schritte ausführen.

Lassen Sie uns gnuplot installieren und starten -

$ 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>

Da wir über das Terminal arbeiten und davon ausgehen, dass keine Grafiken verfügbar sind, können wir das dumme Terminal auswählen, das die Ausgabe in ASCII über das Terminal selbst ausgibt. Dies hilft uns, eine Vorstellung davon zu bekommen, wie unser Plot mit diesem schnellen Tool aussieht. Bereiten wir nun das Terminal für den ASCII-Plot vor.

gnuplot> set terminal dumb

Output

Terminal type set to 'dumb'
Options are 'feed  size 79, 24'

Da unser Gnuplot-Terminal jetzt für den ASCII-Plot bereit ist, zeichnen wir die Daten aus dem out.data Datei -

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

Wir haben die ttime, die Gesamtzeit (in ms) aus Spalte 9 in Bezug auf die Anzahl der Anforderungen aufgetragen. Wir können feststellen , dass für die ersten zehn Anfragen, die Gesamtzeit , in der fast 100 ms war, für die nächsten 30 - Anfragen (10 th bis 40 th ), es bis 1100 ms erhöht, und so weiter. Ihr Grundstück muss je nach Ihrem unterschiedlich seinout.data.

Im vorherigen Kapitel haben wir die grundlegende Verwendung der Apache Bench zum Testen einer Website eines Drittanbieters verstanden. In diesem Abschnitt verwenden wir dieses Tool, um eine Webanwendung auf unserem eigenen Server zu testen. Um das Tutorial so weit wie möglich in sich geschlossen zu halten, haben wir uns entschieden, zu Demonstrationszwecken eine Python-Anwendung zu installieren. Sie können jede andere Sprache wie PHP oder Ruby wählen, abhängig von Ihrem Kenntnisstand.

Python installieren

Im Allgemeinen wird Python standardmäßig auf Linux-Servern installiert.

Installieren von Bottle Framework und Erstellen einer einfachen Anwendung

Bottle ist ein in Python geschriebenes Mikro-Framework zum Erstellen von Webanwendungen, und pip ist ein Python-Paketmanager. Geben Sie den folgenden Befehl in das Terminal ein, um Bottle zu installieren -

$ sudo apt-get install python-pip
$ sudo pip install bottle

Lassen Sie uns jetzt eine kleine Flaschenanwendung erstellen. Erstellen Sie dazu ein Verzeichnis und verschieben Sie es -

$ mkdir webapp
$ cd webapp

Wir werden ein neues Python-Skript erstellen, app.pyim Webapp-Verzeichnis -

$ vim app.py

Schreiben Sie nun den folgenden Code in die Datei 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)

Wenn Sie die obigen Zeilen hinzugefügt haben, speichern und schließen Sie die Datei. Nachdem wir die Datei gespeichert haben, können wir das Python-Skript ausführen, um die Anwendung zu starten.

$ python app.py

Output

Bottle v0.12.7 server starting up (using WSGIRefServer())...
Listening on http://localhost:8080/
Hit Ctrl-C to quit.

Diese Ausgabe zeigt, dass unsere Anwendung auf dem lokalen Computer auf dem Host ausgeführt wird http://localhost und am Hafen lauschen 8080.

Lassen Sie uns überprüfen, ob unsere App ordnungsgemäß auf die HTTP-Anforderungen reagiert. Da dieses Terminal keine Eingaben annehmen kann, ohne die Bottle-Anwendung zu beenden, müssen wir uns mit einem anderen Terminal bei unserem VPS anmelden. Nachdem Sie sich mit einem anderen Terminal beim VPS angemeldet haben, können Sie zu Ihrer Anwendung navigieren, indem Sie den folgenden Code in das neue Terminal eingeben.

$ lynx http://localhost:8080/

Lynx ist ein Befehlszeilenbrowser und wird normalerweise standardmäßig in verschiedenen Linux-Distributionen wie Debian und Ubuntu installiert. Wenn Sie die folgende Ausgabe sehen, bedeutet dies, dass Ihre App einwandfrei funktioniert.

Output

Wenn Sie die obige Ausgabe sehen, bedeutet dies, dass unsere Anwendung live und bereit zum Testen ist.

Testen der Anwendung mit Developmental Web Server

Bitte beachten Sie, dass in ab ein Fehler vorliegt und die Anwendung auf dem localhost nicht getestet werden kann. Daher werden wir den Host in der Datei app.py von localhost auf 127.0.0.1 ändern. Die Datei ändert sich also wie folgt:

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)

Lassen Sie uns nun unsere App testen, indem Sie den folgenden Befehl auf demselben Terminal eingeben, auf dem der Befehl lynx ausgeführt wurde:

$ 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)

Während der Ausgang am ersten Terminal (100-mal) wie folgt ist -

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

Sie können beobachten, wie sich die verschiedenen Werte des ab-Ergebnisses im Vergleich zum ersten Test geändert haben.

Testen der Anwendung mit einem Multithread-Webserver

In den vorherigen Tests von ab haben wir den Standard-Webserver verwendet, der im Bottle-Framework enthalten ist.

Jetzt werden wir den Single-Threaded-Standard-Webserver durch einen Multi-Threaded-Webserver ersetzen. Lassen Sie uns daher eine Multithread-Webserver-Bibliothek wie installierencherrypy oder gunicornund sag Bottle, dass sie es benutzen soll. Wir haben Gunicorn für den Demonstrationszweck hier ausgewählt (Sie können auch ein anderes auswählen) -

$  sudo apt-get install gunicorn

Und ändern Sie die Datei, dh vom Standard-Webserver zum Gunicorn -

...
run(server = 'gunicorn'...)
...

Testen wir die App im zweiten Terminal.

$ 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)

Beobachten Sie, wie sich die Anforderungen pro Sekunde von 493 auf 3252 erhöht haben. Dies bedeutet, dass Gunicorn als Produktionsserver für Python-Apps geeignet ist.

In diesem Kapitel erfahren Sie, wie Sie mehrere URLs gleichzeitig testen. Dazu müssen wir unsere Anwendungsdatei app.py bearbeiten, um zwei URLs einzuschließen -

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)

Erstellen eines einfachen Shell-Skripts

Sie können dies tun, indem Sie ein Shell-Skript mit mehreren ab-Aufrufen erstellen. Erstellen Sie eine Datei test.sh und fügen Sie die folgenden Zeilen hinzu:

ab -n 100 -c 10 http://127.0.0.1:8080/hello1 
ab -n 100 -c 10 http://127.0.0.1:8080/hello2

Wenn Sie die obigen Zeilen hinzugefügt haben, speichern und schließen Sie die Datei. Machen Sie die Datei ausführbar -

chmod u+x test.sh

Lassen Sie uns jetzt das Skript ausführen -

./test.sh

Um Wiederholungen und den Zweck der Klarheit zu vermeiden, zeigen wir nur die relevante Ausgabe von ab an und geben durch Punkte an, welcher Teil weggelassen wurde, wie im Folgenden.

Ausgabe

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

Shell-Skript zum Speichern der Apache Bench-Ausgabe in einer Datei

Sie können die Apache Bench-Ausgabe in einer Datei speichern, indem Sie ein Shell-Skript mit mehreren ab-Aufrufen erstellen. Platzieren Sie am Ende jeder Zeile ein&;Dadurch wird der Befehl im Hintergrund ausgeführt und der nächste Befehl kann ausgeführt werden. Sie möchten auch die Ausgabe für jede URL mit <Dateiname> in eine Datei umleiten. Zum Beispiel sieht unsere Datei test.sh nach der Änderung wie folgt aus:

$ 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 &

Hier, test1.txt und test2.txt sind die Dateien zum Speichern der Ausgabedaten.

Sie können überprüfen, ob das obige Skript zwei Dateien erstellt hat, test1.txt und test2.txt, die die ab-Ausgabe für die jeweiligen URLs enthalten.

$ ls -l

Ausgabe

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

Vorsicht Situation

Während Sie ab verwenden, sollten Sie ohne Vorwarnung auf den fehlgeschlagenen Test aufmerksam sein. Wenn Sie beispielsweise eine falsche URL überprüfen, erhalten Sie möglicherweise etwas Ähnliches wie das Folgende (wir haben den Port hier absichtlich geändert).

$ ab -l -r -n 100 -c 10 -k -H "Accept-Encoding: gzip, deflate"  http://127.0.0.1:805/

Ausgabe

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 diesem Kapitel werden wir die Vorbereitung zum Testen dynamischer Seiten verstehen. Eine serverseitige dynamische Webseite ist eine Webseite, deren Aufbau von einem Anwendungsserver gesteuert wird, der serverseitige Skripts verarbeitet. Die Apache-Bank kann nur die serverseitige dynamische Webseite testen.

Parallelitätsstufe und Gesamtzahl der Anfragen

Die Parallelitätsstufe sollte niedriger sein als die Gesamtzahl der Anforderungen.

$ 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

Verwendung von Flaggen

In diesem Abschnitt beschreiben wir die Verwendung einiger wichtiger Flags mit dem Befehl ab. Wir werden die Begriffe, Optionen und Flags austauschbar verwenden.

Verbose -v

Die ausführliche Option kann zum Analysieren und Debuggen verwendet werden, wenn mehrere fehlgeschlagene Anforderungen vorhanden sind. Ein häufiger Hinweis auf ein Versagen des Lasttests ist, dass der Test sehr schnell beendet wird und eine gute Zahl für die Anforderung pro Sekunde ergibt. Aber es wird ein falscher Maßstab sein. Um den Erfolg oder Misserfolg zu identifizieren, können Sie die verwenden-v 2Option, mit der der Text und der Header jeder Antwort an den Terminalausgang ausgegeben werden. Der folgende Befehl zeigt einen Anwendungsfall -

$ ab -n 1 -v 2 http://www.generic-example-URL.com/

Output

LOG: header received:
HTTP/1.0 200 OK
…
Content-Length: 2548687

Wenn Sie im Falle eines Fehlers variable Antworten testen oder Nicht-200-HTTP-Codes zurückgeben, sollten Sie die Längenprüfung mit einfach ignorieren -lMöglichkeit. Wir werden bald Nicht-200-HTTP sehen, wenn wir in den folgenden Kapiteln eine web2py-Anwendung starten.

Keep-Alive -k

Wenn der Client eine HTTP-Anfrage sendet, wird die Verbindung zum Server hergestellt, der Server sendet die Antwort und die Verbindung wird geschlossen, nachdem er die Anfrage gesendet hat. Dieser Zyklus wird mit jeder Anforderung fortgesetzt. Mit der Keep-Alive-Einstellung (auch als persistente Verbindungen bezeichnet) hält der Client jedoch eine zugrunde liegende TCP-Verbindung offen, um mehrere Anforderungen und Antworten zu ermöglichen. Dies eliminiert die langsame und kostspielige Verbindungsinitialisierungszeit, die sonst vorhanden wäre.

Variable Dokumentlänge -l

Wenn die Webseite eine variable Länge hat, sollten Sie die Option verwenden -l. Apache Bench meldet keine Fehler, wenn die Länge der Antworten nicht konstant ist. Dies kann für dynamische Seiten nützlich sein.

Verwendung der Option -r

Wie kann man ab zwingen, beim Empfang von Fehlern nicht zu beenden? Sie sollten die Option verwenden-r. Ohne diese Option kann Ihr Test abgebrochen werden, sobald eine Anforderung den Socket-Fehler trifft. Mit dieser Option werden jedoch Fehler in der Überschrift "Fehlgeschlagene Fehler" gemeldet, der Test wird jedoch bis zum Ende fortgesetzt.

Verwendung der Option -H

Diese Option wird verwendet, um eine beliebige Kopfzeile hinzuzufügen. Das Argument hat normalerweise die Form einer gültigen Kopfzeile, die ein durch Doppelpunkte getrenntes Feld-Wert-Paar enthält (dh "Accept-Encoding: zip / zop; 8bit").

Verwendung der Option -C

Im folgenden Abschnitt erfahren Sie ausführlich, wie Sie die oben genannten Optionen in Kombination mit der Option zur Verwendung des Cookie-Werts verwenden, d. H. -CMöglichkeit. Die Option -C hat normalerweise die Form aname = valuePaar. Dieses Feld kann wiederholt werden.

Verwenden von Sitzungscookies mit Apache Bench

Um zu verstehen, wie das Cookie mit Apache Bench verwendet wird, benötigen wir eine Webseite, auf der versucht wird, ein Cookie zu setzen. Ein sehr gutes Beispiel ist die web2py-Anwendung, bei der es sich um ein Python-Webframework handelt.

Web2py installieren

Wir werden schnell eine weitere Python-App web2py installieren. Weitere Informationen zur Verwendung finden Sie in der Web2py Framework-Übersicht .

Python wird im Allgemeinen standardmäßig auf dem Ubuntu- und Debian-Server installiert. Daher ist eine Voraussetzung bereits erfüllt, um web2py erfolgreich auszuführen.

Wir müssen jedoch das Entpackungspaket installieren, um die Quelldateien von web2py aus der Zip-Datei zu extrahieren, die wir herunterladen werden.

$ sudo apt-get update
$ sudo apt-get install unzip

Lassen Sie uns das web2py-Framework von der Website des Projekts herunterladen. Wir werden dies in unseren Home-Ordner herunterladen -

$cd ~
$ wget http://www.web2py.com/examples/static/web2py_src.zip

Jetzt können wir die gerade heruntergeladene Datei entpacken und hinein verschieben -

$ unzip web2py_src.zip
$ cd web2py

Um web2py auszuführen, müssen Sie es nicht installieren. Sobald Sie sich im web2py-Verzeichnis befinden, können Sie es ausführen, indem Sie den folgenden Befehl eingeben:

$python web2py.py

Wenn alles erfolgreich ist, wird die folgende Ausgabe angezeigt, in der Sie aufgefordert werden, ein Kennwort für die administrative Benutzeroberfläche auszuwählen.

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

Sie müssen sich jedoch der Tatsache bewusst sein, dass auf die gestartete Weboberfläche nur auf dem lokalen Computer zugegriffen werden kann.

Anhand der Ausgabe können Sie erkennen, dass Sie zum Stoppen des Webservers im Instant-Terminal "STRG-C" eingeben müssen. Um den web2py-Server auf dem anderen Terminal zu stoppen, der sich auf denselben VPS bezieht, können Sie den Befehl kill -SIGTERM <PID> einfügen, wobei <PID> die Prozess-ID für den web2py-Server ist, in diesem Fall 23904.

Sitzungscookie von web2py

Wenn eine Seite nur für einen angemeldeten Benutzer zugänglich ist und nicht direkt über die Anmeldeseite zugänglich ist, können Sie in diesem Fall die verwenden -CFlagge. Dieses Flag definiert ein Cookie für den Befehl ab. Sie müssen jedoch den Wert des Sitzungskennungs-Cookies aus einer gültigen Sitzung abrufen. Wie bekomme ich das? Verschiedene Online-Tutorials führen Sie zu den Browser-Entwicklertools von Chrome (oder Mozilla). In unserem Testfall verwenden wir den Luchsbrowser, um den Wert zu erhalten, da die Anwendung nur in der Befehlszeile verfügbar ist.

Lassen Sie uns zuerst den Cookie-Wert einer Sitzung ermitteln. Öffnen Sie ein anderes Terminal und geben Sie den folgenden Befehl ein:

$ lynx http://127.0.0.1:8000/

Als Antwort auf den obigen Befehl bittet lynx Sie um Erlaubnis, das Cookie vom web2py-Server zu akzeptieren, wie in der Abbildung unten gezeigt.

Notieren Sie sich den Cookie-Wert, bevor Sie eingeben yden Cookie zu akzeptieren. Jetzt sieht das Terminal ähnlich aus wie auf dem folgenden Bild - Website auf dem Terminal!

Nachdem wir den Cookie-Wert erhalten haben, führen wir nun den ab-Test durch. Dazu müssen wir das dritte Terminal öffnen (siehe Bild unten) -

Verwenden wir nun das Flag -C im dritten Terminal -

$ ab -n 100 -c 10 -C session_name = 127.0.0.1-643dad04-3c34  http://127.0.0.1:8000/

Ausgabe

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)

Aus der obigen Ausgabe gehen wir auf einige Punkte ein. Erstens verwendet web2py den Rocket -Webserver. Wir stellen außerdem fest, dass wir zusätzlich zu den zuvor diskutierten Überschriften in der Ausgabe "Nicht-2xx-Antworten" erhalten. Im Allgemeinen antwortet das HTTP-Protokoll auf eine Anfrage mit einem Antwortcode, und alles im Bereich von 200 bedeutet "OK", und der Rest entspricht einem Problem. Zum Beispiel sind 400s ressourcenbezogene Fehler wie 404 File Not Found. 500s entsprechen Serverfehlern. In unserem vorliegenden Fall tritt nirgendwo ein Fehler auf, außer wenn wir die Option -C verwenden. Sie kann mit der Option -l wie bereits beschrieben unterdrückt werden.

Admin-Seite überprüfen

In diesem Abschnitt erfahren Sie, wie Sie die Administrationsseite überprüfen. Lassen Sie uns zum Vergleich eine andere URL der web2py-Anwendung testen -

$ ab -n 100 -c 10 session_name = 127.0.0.1-643dad04-3c34  http://127.0.0.1:8000/admin

Ausgabe

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)

Beachten Sie insbesondere die entsprechenden Statistiken in den Abschnitten „Verbindungszeiten“ und „Prozentsatz der zugestellten Anfragen…“ von http://127.0.0.1:8000/ und http://127.0.0.1:8000/admin. Es gibt einen großen Unterschied.

Verwenden der Timelimit-Option

Im Allgemeinen ist die Timelimit-Option schwierig. Lassen Sie uns dies aus dem Handbuch von ab verstehen , das ziemlich erklärend ist -

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

Lassen Sie uns mit dieser Option einen Test durchführen. Wir werden unsere Beobachtungen nach dem Durchlaufen der Ausgabe notieren -

$ ab -n 100 -c 10 -t 60   http://127.0.0.1:8000/

Ausgabe

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)

Beachten Sie, dass die Ausgabe zeigt, dass diese Option die Anzahl der von der angegebenen Anforderungen überschreibt -nOption und fährt bis zu den 50.000 Anfragen fort. Da die Anfragen jedoch sehr schnell bearbeitet wurden, wurde ab beendet, sobald die 50.000-Marke erreicht wurde - im vorliegenden Fall innerhalb von 22 Sekunden (siehe Überschrift Zeit für Tests).

Sie können das Ersetzen des gleichen Befehls testen http://127.0.0.1:8000/ mit http://127.0.0.1:8000/admin (vorausgesetzt, es handelt sich um unsere web2py-Anwendung) oder eine Website eines Drittanbieters wie https://www.apache.org/, beachten Sie den Unterschied in der Statistik.

Checkliste vor Durchführung des Belastungstests

Es gibt einige Überprüfungen, mit denen Sie den Test erfolgreich ausführen und die Leistung genau messen können. Beachten Sie die folgenden Bedingungen, bevor Sie den Belastungstest durchführen:

  • Stellen Sie sicher, dass kein zusätzliches Python-Modul geladen ist.

  • Um eine Erschöpfung des TCP / IP-Ports zu vermeiden, sollten Sie normalerweise 2-3 Minuten warten, bevor Sie zu einem anderen Ab-Test wechseln.

  • Stellen Sie sicher, dass die Anzahl der gleichzeitigen Verbindungen geringer ist als bei Apache Worker-Threads.

  • Sie sollten den Server neu starten, bevor Sie einen weiteren Test durchführen, wenn Apache oder Python abstürzen.

In diesem Kapitel werden die verschiedenen Kombinationen von beschrieben -n und -c mit den wichtigen Flags, um die Belastung Ihres Webservers schrittweise zu erhöhen.

Sie sollten sich hauptsächlich darauf konzentrieren, wie sich die folgenden Metriken ändern, wenn Sie die Last erhöhen -

  • Anfragen pro Sekunde
  • Verbindungszeiten (ms)
  • Prozentsatz der Anfragen, die innerhalb einer bestimmten Zeit (ms) bearbeitet wurden

Sie sollten auch den Schwellenwert beachten, wenn der Server hängen bleibt und Sie fehlgeschlagene Anforderungen erhalten.

1 Gleichzeitiger Benutzer, der 100 Seitentreffer ausführt

Lassen Sie uns 100 aufeinanderfolgende Seitenladevorgänge durch einen einzelnen Benutzer durchführen -

$ ab -l -r -n 100 -c 1 -k -H "Accept-Encoding: gzip, deflate"  http://127.0.0.1:8000/

Ausgabe

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 gleichzeitige Benutzer, die jeweils 10 Seitentreffer ausführen

Dieser Fall entspricht einer Spitzenlast auf einer Website, die mehr als 50.000 Zugriffe pro Monat erzielt.

$ ab -l -r -n 10 -c 5 -k -H "Accept-Encoding: gzip, deflate"  http://127.0.0.1:8000/

In den folgenden nachfolgenden Ausgaben wird der allgemeine Header aus Gründen der Übersichtlichkeit weggelassen.

Ausgabe

...
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 gleichzeitige Benutzer, die jeweils 10 Seitentreffer ausführen

Dieser Test entspricht 100 Seitenladevorgängen von 10 verschiedenen gleichzeitigen Benutzern. Jeder Benutzer führt 10 aufeinanderfolgende Seitenladevorgänge durch.

$ ab  -r -n 10 -c 10 -k -H "Accept-Encoding: gzip, deflate"  http://127.0.0.1:8000/

Ausgabe

...
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 gleichzeitige Benutzer, die jeweils 20 Seitentreffer ausführen

Dieser Test entspricht 400 Seitenladevorgängen von 20 verschiedenen gleichzeitigen Benutzern. Jeder Benutzer führt 20 aufeinanderfolgende Seitenladevorgänge durch.

$ ab -r -n 20 -c 20 -k -H “Accept-Encoding: gzip, deflate” http://127.0.0.1:8000/

Ausgabe

...
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 gleichzeitige Benutzer, die jeweils 30 Seitentreffer ausführen

Dieser Test entspricht 900 Seitenladevorgängen von 30 verschiedenen gleichzeitigen Benutzern. Jeder Benutzer führt 30 aufeinanderfolgende Seitenladevorgänge durch.

$ ab  -r -n 30 -c 30 -k -H "Accept-Encoding: gzip, deflate"  http://127.0.0.1:8000/

Ausgabe

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

Wir haben jetzt gelernt, wie Sie die Auslastung der Website schrittweise erhöhen und ihre Leistung testen können.

In diesem Kapitel werden wir die Ausgaben mit und ohne Flags vergleichen. Lassen Sie uns sehen, wie die Verwendung geeigneter Flags die Leistung Ihrer Webanwendung steigern kann. Vorher müssen wir verstehen, wie Sie den Unterschied möglicherweise nicht bemerken, wenn Ihre Anwendung einfach ist. Wie bei unserer einfachen Anwendung, mit Flags und ohne Flags. Dann werden wir den gleichen Test mit durchführenhttps://www.apache.org/ URL, und sehen Sie den Unterschied.

Testen unserer Anwendung ohne Flaggen

In diesem Abschnitt erfahren Sie, wie Sie unsere Anwendung ohne Flags testen.

$ ab -n 100 -c 10 http://127.0.0.1:8000/

Ausgabe

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)

Testen unserer Anwendung mit Flags

In diesem Abschnitt erfahren Sie, wie Sie unsere Anwendung mit Flags testen.

$ ab -l -r -n 100 -c 10 -k -H "Accept-Encoding: gzip, deflate"  http://127.0.0.1:8000/

Ausgabe

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

Wir können einfach feststellen, dass es keinen großen Unterschied zwischen den Ausgabestatistiken gibt.

Testen der Apache Organization-Website ohne Flags

Lassen Sie uns nun sehen, wie Sie die Apache Organization-Website ohne Flags testen können.

$ ab -n 100 -c 10 http://www.apache.org/

Ausgabe

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)

Testen der Apache Organization-Website mit Flags

Lassen Sie uns nun die Apache Organization Website mit Flags testen.

$ ab -l -r -n 100 -c 10 -k -H "Accept-Encoding: gzip, deflate"  http://www.apache.org/

Ausgabe

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

Sie können einfach feststellen, wie sich die Anforderung pro Sekunde durch die Verwendung von Flags erhöht hat. Im vorliegenden Fall ist es insbesondere auf die Verwendung von zurückzuführen-H "Accept-Encoding: gzip, deflate, da dieses Flag den Apache-Server anweist, Anforderungen zu bearbeiten gzipped Format.

Berücksichtigung der Apache Bench Ergebnisse

Bei den Ergebnissen der Apache Bench müssen einige wichtige Punkte berücksichtigt werden. Dies wird uns helfen, unsere Gesamtstrategie zu entwerfen, um die Engpässe in unserer Anwendung zu beseitigen und ihre Leistung zu verbessern.

Wir müssen Anfragen pro Sekunde stellen. Dies gibt uns eine Vorstellung davon, wie gut unsere Webserver-Einrichtung funktioniert. Je größer die Zahl, desto besser die Leistung. Dann kommen die Verbindungszeiten (ms) und der Prozentsatz der zugestellten Anfragen. Möglicherweise müssen Sie die Einstellungen Ihres Webservers anpassen, um diese Metriken auf die gewünschte Leistung zu ändern.

Überprüfen Sie, ob die Fehlerprotokolle oder (allgemeinen) Protokolle des Apache oder des verwendeten Webservers fehlerhaft sind. Wenn Sie Ihre Last erhöhen, werden die Dinge ersticken: Speicherprobleme treten auf. Viele Python-Skripte stürzen ab, wenn sie nicht unter Berücksichtigung der Parallelität geschrieben wurden.

Sie müssen herausfinden, über welchem ​​kritischen Wert für die Parallelität Ihr Webserver abstürzt und / oder eine Zeitüberschreitung auftritt. Normalerweise sollte dies bei einer ziemlich hohen Parallelität geschehen. Wenn dieser Wert niedrig ist, stimmt etwas nicht und Sie müssen diese Einstellungen niedriger / höher einstellen.

Fazit

In diesem Tutorial haben wir gelernt, wie Apache Bench zum Laden von Tests für Websites oder Webanwendungen verwendet werden kann. Apache Bench kann ein sehr wertvolles Tool sein, um zu bestimmen, wie das Setup Ihres Webanwendungsservers verbessert werden sollte, um Engpässe zu reduzieren und die Leistung zu steigern. Nachdem Sie mit der grundlegenden Verwendung von Apache Bench vertraut sind, können Sie zunächst neue Testpläne erstellen, um die Leistung Ihrer Anwendungen in verschiedenen Szenarien zu messen.