Der Wettstreit der WEB-Server. Teil 2 – ein realistisches Szenario für HTTPS:

Wir haben in der dem ersten Teil Artikel über die Methode gesprochen, in diesem testen wir HTTPS, jedoch in realistischeren Szenarien. Für den Test wurde ein Let’s Encrypt-Zertifikat erhalten und Brotli-Kompression auf Stufe 11 aktiviert.

Diesmal versuchen wir, ein Szenario für die Bereitstellung eines Servers auf VDS oder als virtuelle Maschine auf einem Host mit einem Standardprozessor nachzubilden. Dazu haben wir folgende Limits festgelegt:

• 25 % – was auf eine Frequenz von etwa 1350 MHz hinausläuft.
• 35 % – 1890 MHz.
• 41 % – 2214 MHz.
• 65 % – 3510 MHz.

Die Anzahl gleichzeitiger Verbindungen wurde von 500 auf 1, 3, 5, 7 und 9 reduziert,

Ergebnisse:

Latenzen:

TTFB wurde speziell als separater Test hervorgehoben, weil HTTPD Tools für jede einzelne Anfrage gewissermaßen einen neuen Benutzer erstellt. Dieser Test ist weiterhin relativ von der Realität entfernt, denn ein Benutzer wird dennoch auf einige Seiten klicken, und in der Realität wird TTFP eine Hauptrolle spielen.

Die erste, eigentlich der allererste Request nach dem ersten Start der virtuellen IIS-Maschine hat im Durchschnitt eine Bearbeitungszeit von 120 ms.

Alle nachfolgenden Anfragen zeigen TTFP von 1,5 ms. Apache und Nginx hinken hierbei hinterher. Der Autor persönlich hält diesen Test für den aussagekräftigsten und würde den Gewinner nur anhand dieses Tests wählen.
Das Ergebnis ist nicht überraschend, da IIS bereits komprimierte statische Inhalte cachet und diese nicht bei jedem Zugriff erneut komprimiert.

Verbrauchte Zeit pro Kunde

Für die Leistungsbewertung genügt ein Test mit einer einzigen gleichzeitigen Verbindung.
Zum Beispiel hat IIS den Test mit 5000 Benutzern in 40 Sekunden abgeschlossen, was 123 Anfragen pro Sekunde entspricht.

In den nachstehenden Diagrammen wird die Zeit bis zur vollständigen Übertragung des Webseiteninhalts dargestellt. Dies ist der Anteil der Anfragen, die in einer bestimmten Zeit verarbeitet wurden. In unserem Fall wurden 80 % aller Anfragen in 8 ms von IIS und in 4,5 ms von Apache und Nginx verarbeitet, während 98 % aller Anfragen auf Apache und Nginx innerhalb von 8 Millisekunden abgewickelt wurden.

Zeit, die benötigt wurde, um 5000 Anfragen zu bearbeiten:

Zeit, die benötigt wurde, um 5000 Anfragen zu bearbeiten:

Wenn Sie eine virtuelle Maschine mit einem 3,5 GHz Prozessor und 8 Kernen haben, wählen Sie, was Sie möchten. Alle Webserver sind in diesem Test sehr ähnlich. Welcher Webserver für jeden Host geeignet ist, werden wir weiter unten besprechen.

Wenn es um eine etwas realistischere Situation geht, liegen alle Webserver gleichauf.

Throughput:

Die Verzögerungskurve in Abhängigkeit von der Anzahl gleichzeitiger Verbindungen. Je flacher und niedriger, desto besser. Die letzten 2 % wurden aus den Grafiken entfernt, da sie unleserlich wären.

Betrachten wir nun die Variante, bei der der Server auf virtuellem Hosting platziert ist. Nehmen wir 4 Kerne mit 2,2 GHz und einen Kern mit 1,8 GHz.

Wie skalieren sie

Wenn Sie jemals gesehen haben, wie die WPL von Elektro-Vakuumtrioden, Pentoden usw. aussehen, werden Ihnen diese Grafiken bekannt vorkommen. Genau das versuchen wir einzufangen – die Sättigung. Der Punkt, an dem die Leistungsteigerung nicht mehr bemerkbar ist, egal wie viele Kerne man hinzufügt.

Früher bestand die gesamte Herausforderung darin, 98 % der Anfragen mit der geringstmöglichen Verzögerung zu verarbeiten und die Kurve so gleichmäßig wie möglich zu halten. Nun werden wir mit der Konstruktion einer anderen Kurve den optimalen Arbeitspunkt für jeden der Server finden.

Dazu nehmen wir die Kennzahl Requests per second (RPR). Auf der horizontalen Achse die Frequenz, auf der vertikalen – die Anzahl der Anfragen, die pro Sekunde bearbeitet werden, und die Linien repräsentieren die Anzahl der Kerne.

Es wird die Korrelation dargestellt, wie gut Nginx die Anfragen nacheinander verarbeitet. 8 Kerne zeigen in einem solchen Test die besten Ergebnisse.

In diesem Diagramm ist deutlich zu sehen, wie viel besser (nicht viel) Nginx auf einem Kern funktioniert. Wenn Sie Nginx verwenden, sollten Sie in Erwägung ziehen, die Anzahl der Kerne auf eins zu reduzieren, wenn Sie nur statische Inhalte hosten.

Obwohl IIS laut DevTools in Chrome die niedrigste TTFB hat, scheitert er in einem ernsthaften Stress-Test der Apache Foundation sowohl gegen Nginx als auch gegen Apache.

Die gesamte Verzerrung der Diagramme wird präzise reproduziert.

Eine Art Fazit:

Ja, Apache funktioniert nachweislich schlechter auf 1 und 8 Kernen, während es auf 4 Kernen etwas besser abschneidet.

Ja, Nginx verarbeitet auf 8 Kernen Anfragen besser nacheinander, auf 1 und 4 Kernen ist die Leistung schlechter, wenn viele Verbindungen vorhanden sind.

Ja, IIS favorisiert 4 Kerne für Multithreading-Belastungen und bevorzugt 8 Kerne für Single-Thread-Anwendungen. Letzten Endes war IIS bei hoher Last auf 8 Kernen etwas schneller als alle anderen, auch wenn alle Server gleichauf waren.

Dies ist kein Messfehler, die Toleranz liegt bei maximal ±1 ms bei den Latenzen und nicht mehr als ±2-3 Anfragen pro Sekunde für RPR.

Die Ergebnisse, wenn 8 Kerne schlechter abschneiden, sind keineswegs überraschend; viele Kerne und SMT/Hyperthreading verschlechtern die Leistung erheblich, wenn wir Zeitvorgaben haben, innerhalb derer wir den gesamten Pipeline-Prozess abschließen müssen.

Quelle: habr.com