In diesem Artikel werden wir uns sozusagen im Reverse Engineering versuchen. Wir werden unsere schmutzigen Hände unter die Haube jedes Webservers stecken und ihn auf eine Weise ausnutzen, die niemand jemals ausnutzen würde.
Dieser Test ist eine Messung eines kugelförmigen Pferdes im Vakuum, nichts weiter als Daten, die gewonnen 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. Vor den Tests erhielten alle Betriebssysteme die neuesten Updates mit Stand vom 04.12.2019. Dezember XNUMX.
Die Tests wurden ausschließlich über HTTP durchgeführt. Auf jedem Webserver wurde dieselbe Seite ausgeführt, eine kostenlose Jekyll-Vorlage von Codrops. . Auf jedem Webserver war die GZIP-Komprimierung deaktiviert.
Der Durchsatztest wurde mit Httpd-tools mit den Argumenten durchgeführt:
ab -n 50000 -c 500 http://192.168.76.204:80/Die Server waren auf 10, 5 und 1 Prozent des Kerns auf 8, 4 und einen Kern beschränkt. Der Prüfstand war ein Computer mit 9900K@5400MHz, was bedeutet, dass der Server, der eine 10%-Grenze erhält, etwa 540MHz pro Kern erhält.
Der TTFB-Test wurde beim ersten Booten des Servers durchgeführt und mit DevTools gemessen; nach Erhalt des Ergebnisses wurde der Server ausgeschaltet und zum vorherigen Prüfpunkt zurückgesetzt, um das Auftreten von Caches jeglicher Art zu verhindern.
Der Tester und der Webserver befanden sich auf demselben Host und auf demselben virtuellen Switch.
Um das Festplatten-Subsystem sofort auszuwerten, sollten Sie die Ergebnisse der ATTO- und CrystalDIskMark-Benchmarks heranziehen, um eine Vorstellung von den Engpässen zu bekommen.
Daten aus der virtuellen Maschine:
Ergebnisse:
TTFB:
Die durchschnittliche TTFB für IIS ist mit 0,5 ms am kleinsten, im Vergleich zu 1,4 ms für Apache und 4 ms für Nginx.
Durchsatz:
Schauen wir uns zunächst an, wie gut jeder Server basierend auf der Anzahl der Kerne skaliert.
Die Grafik zeigt die Anzahl der Testeraufrufe an den Webserver und die Latenz. Die Grafik zeigt, dass NGINX 98 % aller Anfragen verarbeitet und die Site in 20 ms oder weniger bereitgestellt hat. IIS hat wie Apache die letzten 5 % aller Aufrufe in 76 ms bzw. 14 ms abgeschlossen.
Die Grafik zeigt die durchschnittliche Bearbeitungszeit für eine Anfrage während eines Stresstests.
Wie Sie den Grafiken entnehmen können, hat IIS sowohl Apache als auch Nginx umgehauen und bei hoher Last erheblich langsamer gemacht.
IIS bevorzugte eindeutig 4 Kerne gegenüber XNUMX und zeigte geringere Latenzen bei XNUMX, bevorzugte aber auch keinen Kern.
NGINX lässt sich gut über alle 8 Kerne skalieren und für Apache scheint das Single-Core-Szenario die beste Wahl zu sein.
Skalierbarkeit:
Nginx:
Schauen wir uns nun die Skalierbarkeit in Bezug auf Frequenz und Anzahl der Kerne an.
Nginx hat Tests mit einer Grenze von 1 % für 4 und 1 Kerne nicht bestanden; bei mehr als 2000 Anfragen brach es die Verbindung mit dem Tester ab.
Apache:
Apache gab wie Nginx nach der Verarbeitung von 2500 Anfragen auf und schloss die Verbindung. Apache hat den Test auf 8, 4 und 1 Kernen mit einer Grenze von 1 % nicht bestanden, aber darüber hinaus hat es den Test auch mit einer Grenze von 5 % auf einem Kern nicht bestanden, was schlechter ist als Nginx
IIS:
Während der Tests sammelte IIS eine riesige Warteschlange an Anfragen an, verarbeitete jedoch jede einzelne davon. Anscheinend sind standardmäßig keine Zeitüberschreitungen für die Anforderungsverarbeitung festgelegt.
Das Diagramm zeigt die Zeit, die für den Abschluss des Tests benötigt wurde. Völlig absurde Testkonfigurationen wurden verworfen. Das Diagramm zeigt, wie anspruchsvoll IIS in Bezug auf die Hardware ist und wie wunderbar NGINX ist.
Skalierbarkeit von der Festplatte:
Nginx:
Schauen wir uns nun die Skalierbarkeit in Bezug auf Frequenz und Anzahl der Kerne sowie Festplattengeschwindigkeit an.
Dieses Mal hat Nginx vier statt zwei Tests nicht bestanden.
Apache:
Apache hat die gleiche Anzahl an Tests nicht bestanden wie beim letzten Mal.
IIS:
IIS zeigt ein nahezu identisches Diagramm, als gäbe es keine Festplattenbeschränkungen. Im Allgemeinen hat sich an der Grafik aller Server nicht viel geändert, was bedeutet, dass jeder von ihnen statische Daten im RAM zwischengespeichert und von dort aus bereitgestellt hat. Hier sehen wir den größten Engpass – den Webserver selbst.
Es ist noch zu früh, aus diesen 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.
Source: habr.com