Die Schlacht der WEB-Server. Teil 1 – losgelöst von der Realität HTTP:

In diesem Artikel versuchen wir uns im Reverse Engineering, könnte man sagen. Wir schauen mit unseren schmutzigen Händen unter die Haube jedes Webservers und nutzen sie aus, wie es niemand jemals tun würde.

Dieser Test ist eine Messung des sphärischen Pferdes im Vakuum, nicht mehr als Daten, die erfasst wurden, und wir wissen jetzt nicht, was wir damit machen sollen.

Methodik

Als Betriebssystem für Nginx und Apache dient Ubuntu 18.04 LTS, für IIS Windows Server Core 2019. Alle Betriebssysteme erhielten vor den Tests die neuesten Updates mit Stand 04.12.2019.

Die Tests wurden ausschließlich über HTTP durchgeführt. Auf jedem der Webserver lief dieselbe Seite, eine kostenlose Vorlage für Jekyll von Codrops. Link. Auf jedem der Webserver war die gzip-Komprimierung deaktiviert.

Der Durchsatztest wurde mit Httpd-tools und folgenden Argumenten durchgeführt:

ab -n 50000 -c 500 http://192.168.76.204:80/

Auf die Server wurde eine Beschränkung von 10, 5 und 1 Prozent pro Kern auf 8, 4 und einem Kern gesetzt. Als Teststand diente ein Computer mit 9900K@5400MHz, was bedeutet, dass der Server, der auf 10 % begrenzt wurde, etwa 540 MHz pro Kern erhält.

Der TTFB-Test wurde beim ersten Laden des Servers durchgeführt und mit den DevTools gemessen. Nach Erhalt des Ergebnisses wurde der Server heruntergefahren und auf den vorherigen Wiederherstellungspunkt zurückgesetzt, um die Entstehung jeglicher Art von Caches auszuschließen.

Der Tester und der Webserver befanden sich auf demselben Host und demselben virtuellen Switch.

Um die Disk-Subsystem sofort zu bewerten, zeigen die Benchmark-Ergebnisse von ATTO und CrystalDiskMark die Engpässe auf.

Die Daten stammen aus einer virtuellen Maschine:

Ergebnisse:

TTFB:

Der durchschnittliche TTFB bei IIS ist der niedrigste, 0,5 ms, im Vergleich zu 1,4 ms bei Apache und 4 ms bei Nginx.

Durchsatz:

Zuerst betrachten wir, wie gut sich jeder der Server bei der Anzahl an Kernen skalieren lässt.

Im Diagramm ist die Anzahl der Anfragen des Testers an den Webserver und die Latenz dargestellt. Es ist zu sehen, dass NGINX 98 % aller Anfragen bearbeitet hat und die Website in 20 ms oder weniger geliefert wurde. IIS und Apache benötigten für die letzten 5 % aller Anfragen 76 ms bzw. 14 ms.

Im Diagramm ist die durchschnittliche Bearbeitungszeit einer Anfrage während des Stresstests dargestellt.

Wie aus den Diagrammen hervorgeht, hat IIS gegen Apache und Nginx verloren und war unter hoher Last stark verlangsamt. 

IIS bevorzugte eindeutig 4 Kerne gegenüber acht und zeigte geringere Latenzen bei vier, war jedoch auch mit einem Kern nicht wirklich zufrieden.

NGINX skaliert hervorragend auf alle 8 Kerne, während für Apache anscheinend ein Ein-Kern-Szenario die beste Wahl zu sein scheint.

Skalierbarkeit:

Nginx:

Betrachten wir nun die Skalierbarkeit in Bezug auf Frequenz und Anzahl der Kerne. 

Tests mit einer 1%-Grenze auf 4 und 1 Kern hat Nginx nicht bestanden, bei über 2000 Anfragen hat es die Verbindung zum Tester abgebrochen.

Apache:

Apache hat wie Nginx 2500 Anfragen bearbeitet, aber letztendlich aufgegeben und die Verbindung getrennt. Apache hat den Test auf 8, 4 und 1 Kern mit einer 1%-Grenze nicht bestanden, zudem hat es auch den Test bei 5% Begrenzung auf einem Kern nicht bestanden, was schlechter ist als Nginx.

IIS:

IIS hat während der Tests einen riesigen Anfragenstau aufgebaut, aber jede einzelne Anfrage bearbeitet. Anscheinend sind in der Standardkonfiguration keine Zeitlimits für die Bearbeitung von Anfragen festgelegt.

Im Diagramm ist die Zeit dargestellt, in der der Test abgeschlossen wurde. Komplett absurde Testkonfigurationen wurden verworfen. Aus dem Diagramm geht hervor, wie anspruchsvoll IIS an die Hardware ist und wie hervorragend NGINX abschneidet.

Skalierbarkeit vom Disk:

Nginx:

Nun betrachten wir die Skalierbarkeit in Bezug auf Frequenz, Anzahl der Kerne und Festplattengeschwindigkeit. 

Dieses Mal hat Nginx 4 Tests nicht bestanden, anstelle von zwei.

Apache:

Apache hat die gleiche Anzahl an Tests wie beim letzten Mal nicht bestanden.

IIS:

IIS zeigt nahezu identische Grafiken, als ob es keine Einschränkungen bezüglich des Disk hätte. Im Großen und Ganzen haben sich die Grafiken aller Server nicht stark verändert, was bedeutet, dass jeder von ihnen den statischen Inhalt im Arbeitsspeicher zwischengespeichert hat und von dort aus ausgeliefert hat. Hier erkennen wir den Hauptengpass – den Webserver selbst.

Es ist zu früh, um auf der Grundlage dieser Tests Schlussfolgerungen zu ziehen, da wir HTTPS, Kompression und HTTP/2 mit einem Live-Zertifikat von Let’s Encrypt noch nicht getestet haben. Darüber werden wir im nächsten Artikel berichten.

Quelle: habr.com