In diesem Artikel versuchen wir uns an Reverse Engineering. Wir werfen unsere dreckigen Hände unter die Haube jedes der Webserver und nutzen sie, wie sie niemals genutzt werden sollten.
Dieser Test ist ein Vergleich, der nichts weiter als ein Datenabtastung darstellt, und jetzt wissen wir nicht, was wir damit anfangen sollen.
Methodik
Als Betriebssystem für Nginx und Apache verwenden wir Ubuntu 18.04 LTS, für IIS den Windows Server Core 2019. Alle Betriebssysteme wurden vor den Tests mit den neuesten Updates bis zum 04.12.2019 versehen.
Die Tests wurden ausschließlich über HTTP durchgeführt. Auf jedem der Webserver lief dieselbe Seite, ein kostenloses Jekyll-Template von Codrops. . Auf jedem der Webserver wurde die Gzip-Kompression deaktiviert.
Der Durchsatztest wurde mit Httpd-tools und den Argumenten durchgeführt:
ab -n 50000 -c 500 http://192.168.76.204:80/Auf den Servern wurde eine Begrenzung von 10, 5 und 1 Prozent der CPU für 8, 4 und einem Kern eingerichtet. Als Teststand diente ein Computer mit einem 9900K@5400MHz, was bedeutet, dass der Server, der eine Begrenzung von 10% erhielt, etwa 540MHz pro Kern erhält.
Der TTFB-Test wurde bei der ersten Server-Ladung 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 im selben virtuellen Switch.
Um die Disk-Subsysteme sofort zu bewerten, wurden die Ergebnisse der Benchmarks ATTO und CrystalDiskMark überprüft, um Engpässe zu identifizieren.
Daten abgerufen von der virtuellen Maschine:
Ergebnisse:
TTFB:
Der durchschnittliche TTFB bei IIS ist der niedrigste, mit 0,5 ms, verglichen mit 1,4 ms bei Apache und 4 ms bei Nginx.
Throughput:
Zuerst betrachten wir, wie gut sich jeder Server hinsichtlich der Anzahl der Kerne skalieren lässt.
Das Diagramm zeigt die Anzahl der Anfragen des Testers an den Webserver und die Latenz. Es ist zu sehen, dass NGINX 98% aller Anfragen bearbeitet hat und die Website in 20 ms oder weniger geliefert hat. IIS und Apache benötigten für die letzten 5% aller Anfragen 76 ms bzw. 14 ms.
Das Diagramm zeigt die durchschnittliche Bearbeitungszeit einer Anfrage während des Stresstests.
Wie aus den Diagrammen ersichtlich ist, hat IIS sowohl gegen Apache als auch gegen Nginx verloren und hat sich bei hoher Last stark verlangsamt.
IIS hat eindeutig 4 Kerne gegenüber 8 vorgezogen und zeigte geringere Latenzzeiten bei 4 Kernen, aber auch eine einzelne Kernkonfiguration wurde nicht stark beworben.
NGINX skaliert hervorragend auf alle 8 Kerne, während für Apache ein einhäufiges Szenario anscheinend die beste Wahl ist.
Skalierbarkeit:
Nginx:
Betrachten wir jetzt die Skalierbarkeit in Bezug auf Taktfrequenz und Anzahl der Kerne.
Tests mit einer Begrenzung von 1% auf 4 und 1 Kern hat Nginx nicht bestanden, da es bei über 2000 Anfragen die Verbindung zum Tester abbrach.
Apache:
Wie Nginx hat Apache bei 2500 Anfragen aufgegeben und die Verbindung abgebrochen. Apache hat den Test bei 8, 4 und 1 Kern mit einer Begrenzung von 1% nicht bestanden, zudem hat es auch den Test mit 5% Beschränkung bei einem Kern nicht überstanden, was schlechter ist als Nginx.
IIS:
IIS sammelte während der Tests eine massive Warteschlange von Anfragen, bearbeitete jedoch jede einzelne. Offensichtlich sind in der Standardkonfiguration keine Timeout-Einstellungen für die Anfrageverarbeitung eingerichtet.
Das Diagramm zeigt die Zeit, die für den Test benötigt wurde. Völlig absurde Testkonfigurationen wurden ausgeschlossen. Aus dem Diagramm wird ersichtlich, wie ressourcenintensiv IIS ist und wie hervorragend NGINX abschneidet.
Skalierbarkeit vom Datenträger:
Nginx:
Lassen Sie uns jetzt die Skalierbarkeit in Bezug auf Frequenz, Anzahl der Kerne und Geschwindigkeit der Festplatte betrachten.
In diesem Test hat Nginx diesmal 4 Tests nicht bestanden, anstatt nur zwei.
Apache:
Apache hat die gleiche Anzahl an Tests nicht bestanden wie beim letzten Mal.
IIS:
IIS zeigt nahezu identische Ergebnisse, als ob es keine Einschränkungen bezüglich der Festplatte gegeben hätte. Insgesamt haben sich die Diagramme der Server nicht stark verändert, was bedeutet, dass jeder von ihnen die statischen Inhalte im Arbeitsspeicher zwischengespeichert und daraus ausgeliefert hat. Hier sehen wir den Hauptengpass – den Webserver selbst.
Es ist zu früh, um auf Basis dieser Tests Schlussfolgerungen zu ziehen; wir haben HTTPS, Kompression und HTTP/2 mit einem Live-Zertifikat von Let’s Encrypt noch nicht getestet. Darüber werden wir im nächsten Artikel berichten.
Quelle: habr.com
