Website Stresstest: Performance / Ladezeit messen verbessern

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 | Translation English |🔔 | Kommentare:0

➚ "Verbindung ist sicher": kostenlose SSL Zertifikate: Let's Encrypt | ➊ Webhosting

Top-Artikel in diesem Bereich


Traefik: Datenverkehr auf einen anderen Server weiterleiten

Als Vorbereitung fĂŒr das Übersiedeln meiner Websites habe ich nach einer Möglichkeit gesucht den kompletten Datenverkehr vom alten Server einfach auf den neuen weiterzuleiten. 


Webserver mit Docker Container umziehen, Theorie und Praxis

Wer einen virtuellen Server oder Cloud-Server mietet, muss diesen fĂŒr ein neues Betriebssystem von Zeit zu Zeit austauschen. SpĂ€testens, wenn fĂŒr das Betriebssystem keine Updates mehr zur VerfĂŒgung gestellt werden, ist ein Serverwechsel unausweichlich. Vor einiger Zeit habe ich alle Websites auf Docker-Container umgestellt, was den Umzug beschleunigen soll. ZunĂ€chst etwas Theorie zu meinen Überlegungen, dann wie mein Serverumzug zuletzt vonstattenging. ZusĂ€tzli...


Systeme ĂŒberwachen: Monitoring in HomeAssistant mit Glances

FĂŒr das Sammeln von Systemdaten anderer Betriebssysteme bietet HomeAssistant unter anderem eine Glances-Integration.  Glances ist ein Terminalprogramm fĂŒr das Überwachen des Systemstatus wie der CPU, Memory oder des Diskverbrauches. Der zusĂ€tzliche WebServer-Mode erlaubt es den Status auch ohne SSH abzurufen. Informationen zur Integration in Home-Assistant, siehe: Home-Assistant. 

Fragen / Kommentare


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