Kann mich bitte jemand durch den Prozess führen, wie ich meine Website mit dem Apache Bench Tool ( ab) laden kann ?
Ich möchte folgendes wissen:
Wie viele Personen pro Minute kann die Site verarbeiten?
Bitte führen Sie mich durch die Befehle, die ich ausführen sollte, um dies herauszufinden.
Ich habe jedes Tutorial ausprobiert und sie sind verwirrend.
Antworten:
Das Apache-Benchmark-Tool ist sehr einfach, und obwohl es Ihnen eine solide Vorstellung von der Leistung gibt, ist es eine schlechte Idee, sich nur darauf zu verlassen, wenn Sie vorhaben, Ihre Site in der Produktion ernsthaften Belastungen auszusetzen.
Trotzdem sind hier die häufigsten und einfachsten Parameter:
-c: ("Parallelität"). Gibt an, wie viele Clients (Personen / Benutzer) gleichzeitig auf die Site zugreifen. Während abder Ausführung werden -cClients auf die Website zugreifen. Dies ist es, was tatsächlich entscheidet, wie viel Stress Ihre Website während des Benchmarks erleiden wird.
-n: Gibt an, wie viele Anfragen gestellt werden sollen. Dies entscheidet nur über die Länge des Benchmarks. Ein hoher -nWert mit einem -cWert, den Ihr Server unterstützen kann, ist eine gute Idee, um sicherzustellen, dass bei anhaltendem Stress nichts kaputt geht: Es ist nicht dasselbe, Stress für 5 Sekunden als für 5 Stunden zu unterstützen.
-k: Dies tun die "KeepAlive" -Funktionsbrowser von Natur aus. Sie müssen keinen Wert für -k"boolean" übergeben (was bedeutet, dass Sie für Ihren Test den Keep Alive-Header von HTTP verwenden und die Verbindung aufrechterhalten möchten). Da Browser dies tun und Sie wahrscheinlich den Stress und den Fluss simulieren möchten, den Ihre Website von Browsern ausgeht, wird empfohlen, damit einen Benchmark durchzuführen.
Das letzte Argument ist einfach der Host. Standardmäßig wird das Protokoll http: // aufgerufen, wenn Sie es nicht angeben.
ab -k -c 350 -n 20000 example.com/
Wenn Sie den obigen Befehl eingeben, erreichen Sie http://example.com/ mit 350 gleichzeitigen Verbindungen, bis 20.000 Anforderungen erfüllt sind. Dies erfolgt über den Keep-Alive-Header.
Nachdem der Prozess die 20.000 Anfragen abgeschlossen hat, erhalten Sie Feedback zu den Statistiken. Hier erfahren Sie, wie gut die Site unter der Belastung funktioniert, die Sie bei Verwendung der oben genannten Parameter ausgesetzt haben.
Um herauszufinden, wie viele Personen die Site gleichzeitig verarbeiten kann, überprüfen Sie einfach, ob die Antwortzeiten (Mittelwerte, minimale und maximale Antwortzeiten, fehlgeschlagene Anforderungen usw.) Zahlen sind, die Ihre Site akzeptieren kann (verschiedene Sites wünschen möglicherweise unterschiedliche Geschwindigkeiten). Sie können das Tool mit verschiedenen -c-Werten ausführen, bis Sie die Stelle erreichen, an der Sie sagen: "Wenn ich es erhöhe, werden fehlgeschlagene Anforderungen angezeigt und es wird unterbrochen."
Abhängig von Ihrer Website erwarten Sie eine durchschnittliche Anzahl von Anfragen pro Minute. Dies ist so unterschiedlich, dass Sie dies mit ab nicht simulieren können. Stellen Sie sich das jedoch folgendermaßen vor: Wenn Ihr durchschnittlicher Benutzer 5 Anfragen pro Minute trifft und die durchschnittliche Antwortzeit, die Sie für gültig halten, 2 Sekunden beträgt, bedeutet dies, dass 10 Sekunden pro Minute 1 Benutzer nur Anfragen haben 1/6 der Zeit wird es die Seite treffen. Dies bedeutet auch, dass, wenn 6 Benutzer gleichzeitig mit ab auf die Site zugreifen, wahrscheinlich 36 Benutzer in der Simulation sind, obwohl Ihre Parallelitätsstufe (-c) nur 6 beträgt.
Dies hängt von dem Verhalten ab, das Sie von Ihren Benutzern bei der Nutzung der Website erwarten. Sie können es jedoch unter "Ich erwarte, dass mein Benutzer X Anforderungen pro Minute erfüllt, und ich halte eine durchschnittliche Antwortzeit für gültig, wenn sie 2 Sekunden beträgt" abrufen. Ändern Sie dann einfach Ihre -c-Stufe, bis Sie 2 Sekunden durchschnittliche Antwortzeit erreichen (stellen Sie jedoch sicher, dass die maximale Antwortzeit und stddev noch gültig sind) und sehen Sie, wie groß Sie -c machen können.
Ich hoffe ich habe das klar erklärt :) Viel Glück
-lOption hinzufügen, wenn die Seite dynamischen Inhalt enthält. Auf diese Weise erhalten Sie keine Reihe fehlgeschlagener Anforderungen, da die Inhaltslänge zwischen den Anforderungen unterschiedlich ist.
Bitte führen Sie mich durch die Befehle, die ich ausführen sollte, um dies herauszufinden.
Der einfachste Test, den Sie durchführen können, besteht darin, 1000 Anforderungen gleichzeitig auszuführen (was ungefähr 10 gleichzeitige Benutzer simuliert, die jeweils 100 Seiten erhalten - über die Länge des Tests).
ab -n 1000 -c 10 -k -H "Accept-Encoding: gzip, deflate" http://www.example.com/
-n 1000 ist die Anzahl der Anfragen.
-c 10 weist AB an, 10 Anfragen gleichzeitig anstelle von 1 Anfrage gleichzeitig auszuführen, um gleichzeitige Besucher (im Vergleich zu sequentiellen Besuchern) besser zu simulieren.
-ksendet den KeepAliveHeader, der den Webserver auffordert, die Verbindung nicht nach jeder Anforderung zu beenden, sondern sie weiterhin wiederzuverwenden.
Ich sende auch den zusätzlichen Header, Accept-Encoding: gzip, deflateda mod_deflate fast immer verwendet wird, um die Text- / HTML-Ausgabe um 25% bis 75% zu komprimieren. Die Auswirkungen sollten nicht verworfen werden, da sie sich auf die Gesamtleistung des Webservers auswirken (d. H. kann 2x die Daten in der gleichen Zeit übertragen, etc).
Ergebnisse:
Benchmarking www.example.com (be patient)
Completed 100 requests
...
Finished 1000 requests
Server Software: Apache/2.4.10
Server Hostname: www.example.com
Server Port: 80
Document Path: /
Document Length: 428 bytes
Concurrency Level: 10
Time taken for tests: 1.420 seconds
Complete requests: 1000
Failed requests: 0
Keep-Alive requests: 995
Total transferred: 723778 bytes
HTML transferred: 428000 bytes
Requests per second: 704.23 [#/sec] (mean)
Time per request: 14.200 [ms] (mean)
Time per request: 1.420 [ms] (mean, across all concurrent requests)
Transfer rate: 497.76 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.1 0 1
Processing: 5 14 7.5 12 77
Waiting: 5 14 7.5 12 77
Total: 5 14 7.5 12 77
Percentage of the requests served within a certain time (ms)
50% 12
66% 14
75% 15
80% 16
90% 24
95% 29
98% 36
99% 41
100% 77 (longest request)
Ignorieren Sie für die einfachste Interpretation alles, ABER diese Zeile:
Requests per second: 704.23 [#/sec] (mean)
Multiplizieren Sie das mit 60, und Sie haben Ihre Anfragen pro Minute.
Um echte Ergebnisse zu erzielen, sollten Sie Wordpress anstelle einer statischen HTML- oder index.php-Datei testen, da Sie wissen müssen, wie alles zusammen funktioniert: einschließlich komplexem PHP-Code und mehreren MySQL-Abfragen ...
Hier sind zum Beispiel die Ergebnisse des Testens einer Neuinstallation von Wordpress auf demselben System und derselben WAMP-Umgebung (ich verwende WampDeveloper, aber es gibt auch Xampp, WampServer und andere) ...
Requests per second: 18.68 [#/sec] (mean)
Das ist jetzt 37x langsamer!
Nach dem Auslastungstest können Sie eine Reihe von Maßnahmen ergreifen, um die Gesamtleistung (Requests Per Second) zu verbessern und den Webserver unter höherer Auslastung stabiler zu machen (z. B. Erhöhung des Apache -nund der -cTendenz zum Absturz von Apache) Sie können hier lesen:
Schritte zum Einrichten von Apache Bench (AB) unter Windows (IMO - Empfohlen).
Schritt 1 - Installieren Sie Xampp.
Schritt 2 - Öffnen Sie CMD.
Schritt 3 - Gehen Sie cd C:\xampp\apache\binvon CMD zum Apache-Bench-Ziel ( ).
Schritt 4 - Fügen Sie den Befehl ein ( ab -n 100 -c 10 -k -H "Accept-Encoding: gzip, deflate" http://localhost:yourport/).
Schritt 5 - Warten Sie darauf. Du bist fertig
Ich war auch neugierig, ob ich die Geschwindigkeit meines Skripts mit Apache abs oder einem PHP-Messskript zum Konstruieren / Zerstören oder einer PHP-Erweiterung messen kann.
Die letzten beiden sind für mich gescheitert: Sie sind ungefähr. Danach dachte ich, ich versuche "ab" und "abs".
Der Befehl "ab -k -c 350 -n 20000 example.com/" ist wunderschön, weil alles einfacher ist!
Aber hat jemand daran gedacht, auf einem Apache-Server "localhost" zu sein, zum Beispiel auf www.apachefriends.org?
Sie sollten einen Ordner wie "Bench" im Stammverzeichnis erstellen, in dem Sie zwei Dateien haben: Testen Sie "Bench.php" und verweisen Sie auf "void.php".
<?php
for($i=1;$i<50000;$i++){
print ('qwertyuiopasdfghjklzxcvbnm1234567890');
}
?>
<?php
?>
"c:\xampp\apache\bin\abs.exe" -n 10000 http://localhost/bench/void.php
"c:\xampp\apache\bin\abs.exe" -n 10000 http://localhost/bench/bench.php
pause
Nun, wenn Sie genau hinschauen ...
Das void-Skript liefert keine Nullergebnisse !!! Die Schlussfolgerung lautet also: Ab dem zweiten Ergebnis sollte das erste Ergebnis verringert werden !!!
hier habe ich:
c:\xampp\htdocs\bench>"c:\xampp\apache\bin\abs.exe" -n 10000 http://localhost/bench/void.php
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 localhost (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests
Server Software: Apache/2.4.33
Server Hostname: localhost
Server Port: 80
Document Path: /bench/void.php
Document Length: 0 bytes
Concurrency Level: 1
Time taken for tests: 11.219 seconds
Complete requests: 10000
Failed requests: 0
Total transferred: 2150000 bytes
HTML transferred: 0 bytes
Requests per second: 891.34 [#/sec] (mean)
Time per request: 1.122 [ms] (mean)
Time per request: 1.122 [ms] (mean, across all concurrent requests)
Transfer rate: 187.15 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.3 0 1
Processing: 0 1 0.9 1 17
Waiting: 0 1 0.9 1 17
Total: 0 1 0.9 1 17
Percentage of the requests served within a certain time (ms)
50% 1
66% 1
75% 1
80% 1
90% 1
95% 2
98% 2
99% 3
100% 17 (longest request)
c:\xampp\htdocs\bench>"c:\xampp\apache\bin\abs.exe" -n 10000 http://localhost/bench/bench.php
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 localhost (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests
Server Software: Apache/2.4.33
Server Hostname: localhost
Server Port: 80
Document Path: /bench/bench.php
Document Length: 1799964 bytes
Concurrency Level: 1
Time taken for tests: 177.006 seconds
Complete requests: 10000
Failed requests: 0
Total transferred: 18001600000 bytes
HTML transferred: 17999640000 bytes
Requests per second: 56.50 [#/sec] (mean)
Time per request: 17.701 [ms] (mean)
Time per request: 17.701 [ms] (mean, across all concurrent requests)
Transfer rate: 99317.00 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.3 0 1
Processing: 12 17 3.2 17 90
Waiting: 0 1 1.1 1 26
Total: 13 18 3.2 18 90
Percentage of the requests served within a certain time (ms)
50% 18
66% 19
75% 19
80% 20
90% 21
95% 22
98% 23
99% 26
100% 90 (longest request)
c:\xampp\htdocs\bench>pause
Press any key to continue . . .
90-17 = 73 das Ergebnis, das ich erwarte!
Das Testen Ihrer API mit nur ab ist nicht ausreichend. Ich denke jedoch, dass es ein großartiges Tool ist, um Ihnen eine grundlegende Vorstellung davon zu geben, wie leistungsfähig Ihre Website ist.
Wenn Sie den Befehl ab verwenden möchten, um mehrere API-Endpunkte mit unterschiedlichen Daten gleichzeitig im Hintergrund zu testen, müssen Sie den Befehl "nohup" verwenden. Es führt einen beliebigen Befehl aus, auch wenn Sie das Terminal schließen.
Ich habe ein einfaches Skript geschrieben, das den gesamten Prozess automatisiert. Sie können es gerne verwenden: http://blog.ikvasnica.com/entry/load-test-multiple-api-endpoints-concurrently-use-this-simple-shell-script