In diesem Artikel werden wir uns im Reverse Engineering versuchen, könnte man sagen. Mit schmutzigen Händen schauen wir unter die Haube der einzelnen Webserver und nutzen sie so aus, wie niemand es jemals getan hätte.
Dieser Test ist eine Messung eines kugelförmigen Pferdes in einem Vakuum, nichts weiter als die Daten, die empfangen wurden, und jetzt wissen wir nicht, was wir damit machen sollen.
Methodik
Das Betriebssystem für Nginx und Apache ist Ubuntu 18.04 LTS für IIS Windows Server Core 2019. Alle Betriebssysteme vor den Tests erhielten die neuesten Updates am 04. Dezember 2019.
Die Tests wurden ausschließlich über HTTP durchgeführt. Jeder Webserver hatte dieselbe Seite, eine kostenlose Vorlage für Jekyll von Codrops.
Link Auf jedem Webserver wurde die gzip-Komprimierung deaktiviert.
Der Bandbreitentest wurde mit Httpd-Tools mit folgenden Argumenten durchgeführt:
ab -n 50000 -c 500 http://192.168.76.204:80/
Die Server waren auf ein Limit von 10, 5 und 1 Prozent des Kerns für 8, 4 und einen Kern festgelegt. Als Prüfstand gab es einen Computer mit 9900K @ 5400 MHz, was bedeutet, dass der Server, der eine 10% -Grenze erhielt, ungefähr 540 MHz pro Kern empfängt.
Der TTFB-Test wurde beim ersten Start des Servers ausgeführt und mit DevTools gemessen. Nach Erhalt des Ergebnisses wurde der Server ausgeschaltet und auf den vorherigen Kontrollpunkt zurückgesetzt, um das Auftreten jeglicher Art von Cache auszuschließen.
Der Tester und der Webserver befanden sich auf demselben Host und auf demselben virtuellen Switch.
Um das Festplattensubsystem sofort zu bewerten, müssen die Ergebnisse der ATTO- und CrystalDIskMark-Benchmarks zum Verständnis der Engpässe herangezogen werden.
Daten, die von der virtuellen Maschine stammen: Ergebnisse:
TTFB:
Der durchschnittliche TTFB für IIS ist mit 0,5 ms der geringste, gegenüber 1,4 ms für Apache und 4 ms für Nginx.Durchsatz:Überlegen Sie zunächst, wie gut sich jeder Server in Bezug auf die Anzahl der Kerne skalieren lässt.
Die Grafik zeigt die Anzahl der Tester-Aufrufe an den Webserver und die Latenz. Die Grafik zeigt, dass NGINX 98% aller Treffer erzielte und die Site für 20 ms oder weniger lief. Sowohl IIS als auch Apache haben 5% aller Anrufe für 76 ms bzw. 14 ms ausgeführt.
Die Grafik zeigt die durchschnittliche Bearbeitungszeit für eine Anfrage während eines Stresstests.
Wie Sie aus den Diagrammen ersehen können, hat IIS sowohl Apache als auch Nginx in die Luft gesprengt und sich unter hoher Last erheblich verlangsamt.
IIS bevorzugte eindeutig 4 Kerne gegenüber 8, was weniger Verzögerungen bei 4 Kernen zur Folge hatte, befürwortete jedoch auch nicht unbedingt einen Kern.
NGINX lässt sich perfekt auf alle 8 Kerne skalieren, und für Apache scheint ein Single-Core-Skript die beste Wahl zu sein.
Skalierbarkeit:
Nginx:Betrachten Sie nun die Skalierbarkeit in Bezug auf Frequenz und Anzahl der Kerne.
Tests mit einem Grenzwert von 1% für 4 und 1 Kernel wurden von Nginx nicht bestanden, so dass 2000 Anforderungen zurückblieben und die Verbindung zum Tester getrennt wurde.
Apache:Apache as Nginx hat 2500 Anfragen bearbeitet und sich ergeben und die Verbindung getrennt. Apache hat den Test nicht mit 8, 4 und 1 Kernel mit einem Limit von 1% bestanden, aber zusätzlich hat der Test mit dem Limit von 5% für einen Kern nicht bestanden, was schlimmer ist als Nginx
IIS:Während der Tests sammelte IIS eine riesige Warteschlange von Anforderungen, verarbeitete jedoch jede einzelne. Offensichtlich sind keine Standardzeitlimits für die Verarbeitung der Anforderung festgelegt.
Das Diagramm zeigt die Zeit, die zum Abschließen des Tests benötigt wurde. Absurd absurde Testkonfigurationen wurden fallengelassen. Das Diagramm zeigt, wie hoch die Anforderungen von IIS an die Hardware sind und wie schön NGINX ist.
Disk Skalierbarkeit:
Nginx:Betrachten Sie nun die Skalierbarkeit in Bezug auf Häufigkeit und Anzahl der Kerne sowie die Festplattengeschwindigkeit.
Diesmal hat Nginx 4 Tests nicht bestanden, sondern zwei.
Apache:Apache hat die gleiche Anzahl von Tests wie beim letzten Mal nicht bestanden.
IIS:IIS zeigt ein fast identisches Diagramm, als gäbe es keine Datenträgereinschränkungen. Im Allgemeinen haben sich die Grafiken aller Server nicht wesentlich geändert, was bedeutet, dass jeder von ihnen die Statik in den Arbeitsspeicher zwischengespeichert und von dort ausgegeben hat. Hier sehen wir den Hauptengpass - den Webserver selbst.
Es ist noch zu früh, um auf der Grundlage dieser Tests Schlussfolgerungen zu ziehen. Wir haben HTTPS, Komprimierung und HTTP / 2 noch nicht mit einem Live-Zertifikat von Let's Encrypt getestet. Wir werden im nächsten Artikel darüber sprechen.
Wir bieten einen aktualisierten UltraLite
Windows VDS- Tarif für 99 Rubel mit installiertem Windows Server 2019 Core an.
