Website Stresstest: Performance / Ladezeit messen verbessern

This page is also available in English

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 zurechtkommt, war ich neugierig, wie viele gleichzeitige Besucher mein Webserver bedienen kann, daher habe ich diesen einem Performancetest unterzogen. 

Antwortzeit der Website

Die Antwortzeit der Website liefert bereits ein Indiz darauf, wie viele Anfragen der Webserver bewältigen kann:

Wie viele Anfragen / Sekunde sind normal?

Laut Google sollte die Ladezeit des Hauptdokuments einer Website 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ür 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 2v CPU 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 mehrheitlich in dieser Dimension ...

Wie kann die Seite beschleunigt werden?

Kaum jemand verwendet heute noch statische Websites, 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 Konfiguration getunt werden, zudem werden heutige dynamische Websites 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 Websites verwenden vornehmlich mehrere Webserver, um die Last aufzuteilen, bzw. kann auch ein Dienst wie Cloudflare vorgeschaltet werden um die Inhalte zu cachen.

Geschwindigkeit testen: Tools

Warnung: bitte nur fĂĽr die eigene Website

Die hier vorgestellten Tools bitte nur für die eigene Website verwenden. Die Loadtests könnten die Website für die Dauer des Tests überfordern bis diese möglicherweise nicht mehr reagiert.

loader.io

Loader.io bietet einen Websites-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:90

Parameter
-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 Website 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 Website 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 Website ist extrem abhängig von der eingesetzten Webapplikation und dem Webserver-Setup. Dynamische Websites 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. 

positive Bewertung({{pro_count}})
Beitrag bewerten:
{{percentage}} % positiv
negative Bewertung({{con_count}})

DANKE fĂĽr deine Bewertung!

Veröffentlichung: 27.03.2021 von Bernhard 🔔


Top-Artikel in diesem Bereich


Nextcloud Server Docker | Einrichtung +https: Let’s Encrypt [ssl]
Um mit meinem NAS Kontakte, Termine und Fotos zu synchronisieren, habe ich Nextcloud getestet und damit anderen Cloudanbietern für meine privaten Daten ein Stück weit den Rücken gekehrt. Dank Docker ist die Installation einfacher und flexibler denn je und ermöglicht es, Nextcloud auf einer beinahe beliebigen Hardware zu betreiben.

Docker Mailserver selbst betreiben | ein Erfahrungsbericht
Mithilfe eines geeigneten Docker-Images ist es relativ einfach einen Mailserver selbst zu betreiben. Ursprünglich habe ich den integrierten Mailserver des Host Europe vServers (Plesk) verwendet und bin bei der Suche nach einem Ersatz auf einen sehr einfachen Docker-Container gestoßen. Der schlanke Container liefert einen Mailserver ohne grafische Verwaltungsoberfläche, kann aber mit wenigen einfachen Befehlen verwaltet werden. Für das Senden und Empfangen der Mails kann ein beliebiger E-Mail-Cli...

sichere https Verbindung: Traefik Reverse Proxy + Let´s Encrypt
Für nahezu alle bekannten Websysteme gibt es fertige Docker-Container, bzw. können diese relativ einfach selbst erstellt oder bestehende Container angepasst werden. Als Docker-Container können die Webservices sehr einfacher installiert und betrieben werden. Wer einen Webservice über das Internet veröffentlicht, sollte dafür heute unbedingt eine verschlüsselte Verbindung (SSL) anbieten. Um den Zugriff auf einen oder mehrere Container zu regeln, kann ein Reverse-Proxy mit kostenlosen Let’s Encrypt...

Fragen / Kommentare


Durch die weitere Nutzung der Seite stimmst du der Verwendung von Cookies zu Mehr Details