Wir haben über die Methodik gesprochen In diesem Artikel testen wir HTTPS, allerdings in realistischeren Szenarien. Zum Testen haben wir ein Let's Encrypt-Zertifikat erhalten und die Brotli-Komprimierung auf 11 aktiviert.
Dieses Mal werden wir versuchen, das Szenario der Bereitstellung eines Servers auf einem VDS oder als virtuelle Maschine auf einem Host mit einem Standardprozessor zu reproduzieren. Zu diesem Zweck wurde eine Grenze festgelegt bei:
- 25 % – was einer Frequenz von ~ 1350 MHz entspricht
- 35 % -1890 MHz
- 41 % – 2214 MHz
- 65 % – 3510 MHz
Die Anzahl der einmaligen Verbindungen wurde von 500 auf 1, 3, 5, 7 und 9 reduziert.
Ergebnisse:
Verzögerungen:
TTFB wurde ausdrücklich als separater Test einbezogen, da HTTPD Tools für jede einzelne Anfrage einen neuen Benutzer erstellt. Dieser Test ist noch recht realitätsfern, da der Nutzer noch einige Seiten anklickt und in der Realität TTFP die Hauptrolle spielt.
Die erste, in der Regel allererste Anfrage nach dem ersten Start der virtuellen IIS-Maschine dauert durchschnittlich 120 ms.
Alle nachfolgenden Anfragen zeigen eine TTFP von 1.5 ms. Apache und Nginx hinken in dieser Hinsicht hinterher. Persönlich hält der Autor diesen Test für den aufschlussreichsten und würde den Gewinner nur auf dieser Grundlage auswählen.
Das Ergebnis ist nicht überraschend, da IIS bereits komprimierte statische Inhalte zwischenspeichert und diese nicht bei jedem Zugriff komprimiert.
Zeitaufwand pro Kunde
Zur Leistungsbeurteilung reicht ein Test mit 1 Einzelverbindung aus.
Beispielsweise hat IIS einen Test mit 5000 Benutzern in 40 Sekunden abgeschlossen, was 123 Anfragen pro Sekunde entspricht.
Die folgenden Grafiken zeigen die Zeit bis zur vollständigen Übertragung des Seiteninhalts. Dies ist der Anteil der in einem bestimmten Zeitraum abgeschlossenen Anfragen. In unserem Fall wurden 80 % aller Anfragen auf IIS in 8 ms und auf Apache und Nginx in 4.5 ms verarbeitet, und 8 % aller Anfragen auf Apache und Nginx wurden innerhalb eines Intervalls von bis zu 98 Millisekunden abgeschlossen.
Zeit, in der 5000 Anfragen bearbeitet wurden:
Zeit, in der 5000 Anfragen bearbeitet wurden:
Wenn Sie eine virtuelle Maschine mit einer 3.5-GHz-CPU und 8 Kernen haben, wählen Sie, was Sie möchten. Alle Webserver sind in diesem Test sehr ähnlich. Im Folgenden besprechen wir, welcher Webserver für jeden Host ausgewählt werden sollte.
Wenn es um eine etwas realistischere Situation geht, liefern sich alle Webserver ein Kopf-an-Kopf-Rennen.
Durchsatz:
Diagramm der Verzögerungen im Vergleich zur Anzahl gleichzeitiger Verbindungen. Glatter und niedriger ist besser. Die letzten 2 % wurden aus den Diagrammen entfernt, da sie dadurch unlesbar würden.
Betrachten wir nun die Option, bei der der Server auf virtuellem Hosting gehostet wird. Nehmen wir 4 Kerne mit 2.2 GHz und einen Kern mit 1.8 GHz.
So skalieren Sie
Wenn Sie jemals gesehen haben, wie die Strom-Spannungs-Kennlinien von Vakuumtrioden, Pentoden usw. aussehen, werden Ihnen diese Diagramme bekannt sein. Das ist es, was wir zu erfassen versuchen: die Sättigung. Die Grenze liegt dann, wenn die Leistungssteigerung unabhängig von der Anzahl der eingesetzten Kerne nicht spürbar ist.
Bisher bestand die gesamte Herausforderung darin, 98 % der Anfragen mit der niedrigsten Latenz für alle Anfragen zu verarbeiten und die Kurve so flach wie möglich zu halten. Indem wir nun eine weitere Kurve erstellen, finden wir den optimalen Betriebspunkt für jeden der Server.
Nehmen wir dazu den Indikator „Anfragen pro Sekunde“ (RPR). Horizontal ist die Häufigkeit, vertikal ist die Anzahl der pro Sekunde verarbeiteten Anfragen, Zeilen sind die Anzahl der Kerne.
Zeigt eine Korrelation, wie gut Nginx Anfragen nacheinander verarbeitet. 8 Kerne schneiden in diesem Test besser ab.
Diese Grafik zeigt deutlich, wie viel besser (nicht viel) Nginx auf einem einzelnen Kern funktioniert. Wenn Sie über Nginx verfügen, sollten Sie erwägen, die Anzahl der Kerne auf einen zu reduzieren, wenn Sie nur statische Kerne hosten.
Obwohl IIS laut DevTools in Chrome die niedrigste TTFB aufweist, gelingt es ihm, in einem ernsthaften Kampf mit dem Stresstest der Apache Foundation sowohl gegen Nginx als auch gegen Apache zu verlieren.
Die gesamte Krümmung der Graphen wird eisenplattiert wiedergegeben.
Eine Art Schlussfolgerung:
Ja, Apache funktioniert auf 1 und 8 Kernen schlechter, auf 4 jedoch etwas besser.
Ja, Nginx auf 8 Kernen verarbeitet Anfragen nacheinander besser, auf 1 und 4 Kernen, und funktioniert schlechter, wenn viele Verbindungen vorhanden sind.
Ja, IIS bevorzugt 4 Kerne für Multithread-Workloads und 8 Kerne für Single-Thread-Workloads. Letztendlich war IIS auf 8 Kernen unter hoher Last etwas schneller als alle anderen, obwohl alle Server gleichwertig waren.
Hierbei handelt es sich nicht um einen Messfehler, der Fehler beträgt hier nicht mehr als +-1ms. in Verzögerungen und nicht mehr als +- 2-3 Anfragen pro Sekunde für RPR.
Die Ergebnisse, bei denen 8 Kerne eine schlechtere Leistung erbringen, sind keineswegs überraschend. Viele Kerne und SMT/Hyperthreading verschlechtern die Leistung erheblich, wenn wir einen Zeitrahmen haben, in dem wir die gesamte Pipeline fertigstellen müssen.
Source: habr.com