{"id":16705,"date":"2026-03-02T23:59:00","date_gmt":"2026-03-02T22:59:00","guid":{"rendered":"https:\/\/u-labs.de\/portal\/?p=16705"},"modified":"2026-03-03T00:23:22","modified_gmt":"2026-03-02T23:23:22","slug":"webserver-lasttests-mit-oha-durchfuehren-auswerten","status":"publish","type":"post","link":"https:\/\/u-labs.de\/portal\/webserver-lasttests-mit-oha-durchfuehren-auswerten\/","title":{"rendered":"Webserver Lasttests mit oha durchf\u00fchren & auswerten"},"content":{"rendered":"

Wie viele Anfragen h\u00e4lt meine Webanwendung bzw. Webseite aus? Bleibt sie dabei stabil? Diese & weitere Fragen lassen sich durch k\u00fcnstlich erzeugte Last kl\u00e4ren. In diesem Beitrag stelle ich das quelloffene Programm Oha<\/em> vor: Es bietet eine Tui-Oberfl\u00e4che und kann die Messwerte exportieren. Dar\u00fcber hinaus gehe ich auf Aspekte ein, welche bei solchen Tests grunds\u00e4tzlich beachtet werden sollten. Repr\u00e4sentativ werden sie durch wiederholte Durchl\u00e4ufe, aus denen wir mit GNU\/Linux Standardwerkzeugen den Durchschnitt berechnen.<\/p>\n

Aufbau & Installation<\/h2>\n

Am einfachsten l\u00e4sst sich Oha<\/em> \u00fcber die Bin\u00e4rdateien starten, welche in den GitHub-Releases ver\u00f6ffentlicht werden.1<\/a><\/sup> Da eine ARM64-Edition existiert, kann man es ebenfalls auf dem Raspberry Pi sowie weiteren Einplatinencomputern nutzen. Zu beachten ist: Im Idealfall liegt der Webserver auf einer eigenen (Virtuellen) Maschine. Das macht den Test um so realistischer im Vergleich zu echten, organischen Besuchern. <\/p>\n

Wie relevant das ist, h\u00e4ngt im wesentlichen davon ab, was man messen m\u00f6chte. Geht es etwa um die Anzahl an Abfragen pro Sekunde, welche eine bestimmte Webanwendung verarbeiten kann, hat eine lokale Ausf\u00fchrung keine Nachteile. Allerdings sollte der Webserver m\u00f6glichst identisch dimensioniert sein, wie das produktive System! Zumindest hinsichtlich des Arbeitsspeichers. Wer mit einem starken Desktop-Prozessor testet, wird bei CPU-Lastigen Anwendungen weitaus bessere Ergebnisse messen, als der \u00e4ltere (und ggf. virtualisierte) Produktivserver.<\/p>\n

Das ausf\u00fchren gegen\u00fcber fremden Seiten ist zu unterlassen! Auch mit eigenen Servern in fremden Rechenzentren ist Vorsicht geboten: Der Test k\u00f6nnte als Angriff erkannt werden.<\/strong><\/p>\n

Der Unterschied zum Browser<\/h2>\n

Oha<\/em> verh\u00e4lt sich nicht wie ein Webbrowser, der per HTTP-GET Anfrage die aufgerufene Adresse (zB \/ f\u00fcr das Wurzelverzeichnis) aufruft, das HTML parst & alle dort referenzierten Ressourcen (CSS, JS, Bilder usw) nachl\u00e4dt. Sowie schlussendlich CSS & JS ausf\u00fchrt, womit ggf. weitere Anfragen folgen – etwa durch Ajax. Stattdessen wird beim Benchmark nur die initiale Anfrage auf die angegebene URL ausgef\u00fchrt, ohne weitere Abh\u00e4ngigkeiten. Das ist kein grunds\u00e4tzliches Problem. Man sollte sich dem jedoch bewusst sein. Die Last bei echten Abfragen kann h\u00f6her sein, wenn z.B. per Ajax weitere dynamisch generierte Aufrufe folgen.<\/p>\n

Theoretisch k\u00f6nnte man X Browser-Instanzen und Fernsteuern, ein bekanntes Framework daf\u00fcr ist Selenium. Das macht jedoch wenig Sinn, weil es schnell an Grenzen st\u00f6\u00dft: Ein vollwertiger Browser verbraucht viele Ressourcen. Selbst auf leistungsstarker Hardware wird das Simulieren mit weniger als einer Hand voll Nutzern schnell scheitern. In aller Regel besteht daf\u00fcr keine Notwendigkeit. Die initiale Anfrage belegt am meisten Ressourcen. Ausnahmen bilden Single-Page-Anwendungen, die eine statische HTML-Seite ausliefern. Per JS rufen sie APIs auf, welche dynamisch generiert mehr Leistung ben\u00f6tigen. Wer das einsetzt, hat sich eine Komplexit\u00e4t geschaffen, die sich bis zu den Tests durchzieht – einfache Werkzeuge wie Oha<\/em> sto\u00dfen dabei an ihre Grenzen.<\/p>\n

Wie viele parallele Prozesse?<\/h2>\n

Die Anzahl an gleichzeitigen Verbindungen sollte an die Konfiguration des Webservers angepasst werden: Anzahl der Arbeitsprozesse von Apache, PHP-FPM usw. Wie dies konkret aussieht, h\u00e4ngt vom eingesetzten Software-Stack ab. Wer beispielsweise PHP-FPM einsetzt, begrenzt die maximale Anzahl an Prozessen mit max_children<\/code>:<\/p>\n

pm.max_children = 50<\/code><\/pre>\n
Erreichen mehr Anfragen den PHP-Server, muss dieser eine Warteschlange bilden. Folglich kommt es zu Verz\u00f6gerungen.<\/p>\n
Bei der Wahl f\u00fcr die Parameter -n (Gesamte Anzahl an Anfragen) und -c (Parallele Verbindungen) sollte die jeweilige Hardware ber\u00fccksichtigt werden. Insbesondere die Gesamtanzahl an Anfragen darf nicht zu niedrig gew\u00e4hlt werden: Kurze Tests liefern weniger aussagekr\u00e4ftige Ergebnisse, weil einzelne Ausrei\u00dfer viel st\u00e4rker ins Gewicht fallen. Statt den gesamten Anfragen daher besser die parallelen Verbindungen reduzieren. <\/p>\n
Durchf\u00fchrung der Messung<\/h2>\n
In diesem Szenario teste ich eine lokale Entwickler-Installation von U-News. Sie hat in ihrer docker-compose.yml sinnvolle Limits gesetzt bekommen, welche der produktiven Umgebung entsprechen. Da U-News bewusst sehr effizient entwickelt wurde, sind 100.000 Anfragen mit 100 parallelen Verbindungen sinnvoll. Der Test l\u00e4uft unter diesen Bedingungen auf einem AMD Ryzen 9 3900X mit RAM-Begrenzung auf 512 MB f\u00fcr Webserver & PHP sowie 1 GB der Datenbank etwa 55 Sekunden lang.<\/p>\n
~\/Downloads\/oha-linux-amd64 --latency-correction --no-pre-lookup -n 100k -c 50 http:\/\/localhost\/<\/code><\/pre>\n
Damit erreiche ich in der Testumgebung einen Durchsatz von etwa 1.600 – 1.800 Anfragen pro Sekunde. W\u00e4hrend die Messung l\u00e4uft, zeigt das linke Diagramm an, wie viele Anfragen in der vergangenen Zeit ausgef\u00fchrt werden konnten. Anfangs im Abstand von einer Sekunde, sp\u00e4ter erfolgt die Gruppierung in 10 Sekunden Bl\u00f6cken. Rechts daneben die Dauer der Anfragen. Daraus l\u00e4sst sich bereits ablesen, dass 100 Anfragen jeweils 4,5s gedauert haben – viel zu lang. Der Webserver ist also bereits \u00fcberlastet und musste Anfragen einreihen. Allerdings konnten sie trotzdem abgearbeitet werden, es kam zu keinen Fehlern. Oben links sind weitere Statistiken sichtbar, sie beziehen sich nur auf die letzten 10 Sekunden. Am Fortschrittsbalken ganz oben ist zu erkennen, wie viele der insgesamt durchzuf\u00fchrenden Anfragen bereits abgearbeitet sind.<\/p>\n
\n
\"\"<\/a><\/figure>\n<\/div>\n
Nach Abschluss gibt Oha<\/em> auf der Konsole einen Bericht aus: 100% Erfolgsrate best\u00e4tigt, dass keine Anfragen mit Fehlern abgebrochen worden sind. Interessant ist der Abstand zwischen schnellster & langsamster Anfrage sowie der Durchschnitt. Wie bereits w\u00e4hrend des Tests ersichtlich, ben\u00f6tigte ein Teil der Anfragen deutlich l\u00e4nger. In welchem Umfang, zeigen die unteren Bereiche besser: 99% sind in 0,0926s oder weniger bearbeitet worden. Die Anfragen pro Sekunde sind eine Metrik, mit denen sich unter identischen Bedingungen gut vergleichen l\u00e4sst, ob etwas effizienter oder weniger effizient ist. Beispielsweise Caching aktivieren oder deaktivieren.<\/p>\n
\n
\"\"<\/a><\/figure>\n<\/div>\n
Repr\u00e4sentative Ergebnisse mit mehr Messungen<\/h2>\n
Obwohl es sich um 100.000 Anfragen handelt, sollte man sich nicht auf lediglich einen einzelnen Durchlauf verlassen. Wer mehrere durchf\u00fchrt, wird Schwankungen feststellen. Keine all zu extremen, sie w\u00fcrden auf Probleme wie beispielsweise \u00e4u\u00dfere Einfl\u00fcsse hinweisen. Mein Test ergab eine Spannbreite von 1.600 Anfragen\/s bis \u00fcber 1.800 Anfragen pro Sekunde bei 10 Durchl\u00e4ufen, das ist normal und kann viele Ursachen haben. Ein klassisches Beispiel: Zwischenspeicher sind anfangs noch leer. Ich empfehle, den Durchschnitt aus f\u00fcnf Messungen zu berechnen. Mindestens drei sollten es sein.<\/p>\n
Requests\/sec: 1634.1302\nRequests\/sec: 1785.7312 \nRequests\/sec: 1829.8046\nRequests\/sec: 1795.9245\nRequests\/sec: 1778.8379\nRequests\/sec: 1606.8775\nRequests\/sec: 1827.2906\nRequests\/sec: 1853.2960\nRequests\/sec: 1856.0149\nRequests\/sec: 1804.9129<\/code><\/pre>\n
Das muss nicht h\u00e4ndisch gemacht werden, sondern l\u00e4sst sich per Skript automatisch wiederholen:<\/p>\n
for i in {1..5}; do\n  ~\/Downloads\/oha-linux-amd64 --latency-correction --no-pre-lookup -n 100k -c 50 http:\/\/localhost\/ | grep Requests\ndone\n  Requests\/sec:\t1836.0231\n  Requests\/sec:\t1484.0862\n  Requests\/sec:\t1557.1620\n  Requests\/sec:\t1494.4489\n  Requests\/sec:\t1513.5794<\/code><\/pre>\n
Automatisches Schreiben & Auswerten der Ergebnisse<\/h2>\n
Praktisch hierf\u00fcr ist die Ausgabe als JSON mittels --output-format json<\/code> sowie optional das Schreiben aller Ergebnisse in eine Datei:<\/p>\n
for i in {1..5}; do\n  ~\/Downloads\/oha-linux-amd64 --latency-correction --no-pre-lookup -n 10k -c 50 --output-format json -o benchmark_$i.json http:\/\/localhost\/\ndone<\/code><\/pre>\n
Das erzeugt die Dateien benchmark_1.json<\/code> bis 5 im aktuellen Ordner. Mit Werkzeugen wie jq<\/code> lassen sie sich parsen und gezielte Attribute abfragen, etwa die Anfragen pro Sekunde. Den Durchschnittswert rechnet uns awk aus:<\/p>\n
jq -r '.summary.requestsPerSec' benchmark_*.json | awk '{sum+=$1; count++} END {print sum\/count}'\n2980.74<\/code><\/pre>\n
F\u00fcr jede Datei gibt jq<\/code> dessen Wert an Abfragen pro Sekunde aus:<\/p>\n
jq '.summary.requestsPerSec' benchmark_*.json \n2968.0908715616397\n3004.999176128391\n5247.248777737877\n2343.4296619530724\n1339.9093700175113<\/code><\/pre>\n
Er wird in awk zur Variable sum<\/em> hinzurechnet. Parallel z\u00e4hlt count<\/em> die Anzahl der Zeilen. Schlussendlich die aufsummierte Anzahl an Anfragen durch die Zahl an Zeilen (und damit Dateien der Messdurchl\u00e4ufe) teilen – in diesem Falle sind das durchschnittlich rund 2981 Anfragen\/s.<\/p>\n
Optimierungen\/Konsequenzen<\/h2>\n
Hier handelt es sich bewusst um ein extremeres Beispiel, um die Grenzen auszutesten. Interessant ist, w\u00e4hrend des Tests die Auslastung des Servers zu beobachten: Der Flaschenhals ist mit einer Auslastung von bis zu 1.700% klar der Prozessor. Das liegt daran, weil hier aktuell noch ein simpler Apache2 mit mod_php (Prefork) eingesetzt wird. Er startet f\u00fcr jede Anfrage einen eigenen Prozess, der au\u00dferdem den PHP-Interpreter aufruft – das ist ineffizient. Mit PHP-FPM lie\u00dfe sich zumindest auf Ebene von PHP die Last deutlich reduzieren. Der Einsatz eines auf Events basierten Webserver wie Nginx statt Apache w\u00fcrde zudem das st\u00e4ndige starten von vollwertigen Prozessen vermeiden.<\/p>\n
In diesem Falle ist das bewusst in Kauf genommen. Die Seite verarbeitet zu Beginn weitaus weniger Anfragen. Au\u00dferdem wollte ich bewusst aufzeigen, wie weit man mit einem Standard-Apache + guten altem mod_php kommt: Damit l\u00e4sst sich bereits einiges realisieren. Selbst auf einem relativ leistungsschwachen Raspberry Pi.<\/p>\n
Je nach Ausgangslage & Ziel kann man nun entscheiden, ob die Werte zufriedenstellend sind. Oder optimiert werden m\u00fcssen. Dabei geht es nicht zwingend um die Anzahl an Anfragen pro Sekunde, dies ist nur ein Beispiel. Daf\u00fcr w\u00e4ren nun Optimierungen des Codes oder Caching geeignete Mittel. Anschlie\u00dfend erneut messen, um Ver\u00e4nderungen zu erfassen.<\/p>\n
Wichtige Parameter f\u00fcr Oha<\/em><\/h2>\n