Webseite Stresstest - Performance messen Anfragen/Sekunde
In der Vergangenheit hat es immer wieder Seiten gegeben, die unter der Last hoher Besucherzahlen zusammengebrochen sind. Obwohl meine Seite bis dato mit den aktuellen Besucherzahlen gut zurecht kommt, war ich neugierig, wie viele gleichzeitige Besucher mein Webserver bedienen kann, daher habe ich diesen einem Performancetest unterzogen.
Antwortzeit der Webseite
Die Antwortzeit der Webseite liefert bereits ein Indiz darauf, wieviele Anfragen der Webserver bewältigen kann:
Wieviele Anfragen / Sekunde sind normal?
Laut Google sollte die Ladezeit des Hauptdokuments einer Webseite unter 200ms sein (Quelle: developers.google.com/speed/docs/insights/mobile). Ein Blick in die Chrome Devtools, F12 im Browser, verrät die Ladezeit der Seite. Das Hauptdokument lässt sich einfach mit "Doc" filtern:
Je höher diese Ladezeit ist, desto mehr Zeit benötigt der Server um die Seite serverseitig zu rendern. Der Wert beinhaltet natürlich auch die Latenz zum Server, sowas zwischen 20 und 70ms. Sollte der Server fürs das Rendern der Seite, sagen wir mal 100ms benötigen, schafft er damit knapp 10 Anfragen / Sekunde. Klar, der Server hat meist mehrere Prozessoren und somit mehrere Threads gleichzeitig am Start und somit mehr Rechenleistung: Wer aber keinen dedizierten Server gemietet hat, teilt sich die Hardware mit anderen. Auch ein vServer oder Cloud-Server mit 2vCPU liefert dann in der Praxis nicht wesentlich mehr als würden die Anfragen einfach der Reihe nach ausgeführt werden. Diese starke Vereinfachung ist so natürlich nicht zulässig, in der Praxis bewegen wir uns bei nur einem Server dennoch meist in dieser Dimension ...
Wie kann die Seite beschleunigt werden?
Kaum jemand verwendet heute noch statische Webseiten, dabei wären Seiten ohne Serverlogik richtig schnell. Je weniger der Server für das Zusammenstellen der Seite rechnen muss, bzw. je weniger Daten der Server aus möglicherweise komplizierten Abfragen aus der Datenbank holen muss, desto schneller kann die Seite zusammengestellt und zum Browser geschickt werden. Ziel ist es also die Rechenzeit für die Seite zu minimieren. Dazu kann der Webserver und dessen Konfig getuned werden, zudem werden heutige dynamische Webseiten meist durch das Cachen bestimmter Teile oder der kompletten Seite beschleunigt. Die Seite wird also beim ersten Aufruf teilweise oder komplett berechnet und das Ergebnis gesondert abgelegt. Beim erneuten Aufruf der Seite werden bereits vorberechnete Ergebnisse für das Ausliefern der Seite herangezogen. Größere Webseiten verwenden meist mehrere Webserver um die Last aufzuteilen, bzw. kann auch ein Dienst wie Cloudflare vorgeschalten werden um die Inhalte zu cachen.
Geschwindigkeit testen: Tools
Warnung: bitte nur für die eigene Webseite
Die hier vorgestellten Tools bitte nur für die eigene Webseite verwenden. Die Loadtests könnten die Webseite für die Dauer des Tests überfordern bis diese möglicherweise nicht mehr reagiert.
loader.io
Loader.io bieteten einen Webseiten-Stresstest als Cloud-Service. Damit der Service nicht missbraucht werden kann, muss die Domain per Text-File am Server vorab bestätigt werden, siehe auch: loader.io
Ähnliche Ergebnisse liefert das kleine http Benchmarking Tool wrt:
wrk - http Benchmark
wrk - Download
Für die Installation wird ein auf Linux basierter Rechner benötigt. Mit folgenden Terminal-Befehlen kann wrk heruntergeladen und für den Einsatz vorbereitet werden:
git clone https://github.com/wg/wrk.git
cd wrk
make siehe auch: https://github.com/wg/wrk
Test des eigenen Webservers: wrk
wrk kann dann einfach über das Terminal mit folgenden Parametern gestartet werden:
./wrk -t4 -c400 -d30s http://127.0.0.1:90Parameter
-t4 ... 4 threads
-c400 ... 400 gleichzeitige Verbindungen
-d30s ... Dauer 30 Sekunden
http://127.0.0.1:90 steht als Beispiel für den lokalen Webserver, wenn der auf Port 90 horcht.
Ergebnis: dynamische Seite vs. statischer Cache
Der Test einer frischen Laravel-Installation und deren Startseite schaut wie folgt aus:
Die Ladezeit beträgt auf meinem lokalen Rechner 59ms für das Laden des Hauptdokumentes, was pro Sekunde und Rechenkern ca. 17 Seiten bedeuten würde. Nachdem mein Rechner 4 Kerne hat und auch die Webseite am selben Gerät läuft, kann der Rechner mehr als doppelt so viele Anfragen verarbeiten: Das Ergebnis von wrk sind 37,34 Anfragen / Sekunde:
./wrk -t4 -c400 -d30s http://127.0.0.1:90
Running 30s test @ http://127.0.0.1:90
4 threads and 400 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 1.32s 391.33ms 1.89s 64.29%
Req/Sec 18.57 16.99 150.00 80.23%
1124 requests in 30.10s, 20.43MB read
Socket errors: connect 0, read 0, write 0, timeout 1096
Requests/sec: 37.34
Transfer/sec: 694.86KB
Cache mit statischen .html Files
Als Beispiel cached das Laravel-Paket von Joseph Silber die Webseite in statische .html-Files. Der Webserver: nginx liefert dabei nur mehr den Inhalt der Files, nachdem diese nach dem ersten Aufruf abgelegt wurden, siehe: github.com/JosephSilber/page-cache
Mit diesem Setup schaut die Sache komplett anders aus:
Die Seite kann in 6ms an den Browser übergeben werden und wrk zeigt bei mir unglaubliche 4766,22 Requests/sec:
./wrk -t4 -c400 -d30s http://127.0.0.1:90
Running 30s test @ http://127.0.0.1:90
4 threads and 400 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 32.99ms 53.77ms 1.99s 94.57%
Req/Sec 1.33k 1.04k 5.49k 71.34%
143362 requests in 30.08s, 2.38GB read
Socket errors: connect 0, read 0, write 0, timeout 1328
Requests/sec: 4766.22
Transfer/sec: 80.89MB
Der Wert kann nicht direkt auf die Anzahl der Besucher umgemünzt werden, da ein Seitenaufruf zusätzliche Assets: Javascript, CSS und Bilder lädt, entsprechend generiert ein Benutzer mehrere Requests. Da hier das Hauptdokument gleich schnell wie die Assets zur Verfügung gestellt wird, hat die Anzahl und Größe der Assets auch eine gewichtigere Rolle als bei einer dynamischen Seite: Bei einer dynamischen Seite ist die Zeit für das Laden des Hauptdokuments der Flaschenhals, bei statischen Files die Anzahl und Größe der Files.
Fazit
Die Performance einer Webseite ist extrem abhängig von der eingesetzten Webapplikation und dem Webserver-Setup. Dynamische Webseiten oder Frameworks sind heute nicht mehr wegzudenken, haben aber einen gewissen Overhead. Die Auswirkung dieses Overheads kann wiederum durch bestimmte Caching-Mechanismen minimiert werden. Neben dem Caching kann der Webserver auch eine bestimmte Rolle spielen, siehe: Erste Erfahrungen mit Laravel Octane 1.0. Die Bandbreite der möglichen Anfragen pro Sekunde schwankt je nach Webserver und Cache-Setup von ein paar Anfragen pro Sekunde bis hin zu mehreren tausend Requests pro Sekunde.
({{pro_count}})
{{percentage}} % positiv
({{con_count}})