Wir haben im
ersten Teil des Artikels über die Technik gesprochen. Dabei haben wir HTTPS getestet, aber in realistischeren Szenarien. Zum Testen wurde das Let's Encrypt-Zertifikat empfangen, die Brotli-Komprimierung um 11 wurde aktiviert.
Dieses Mal versuchen wir, das Serverbereitstellungsszenario auf VDS oder als virtuelle Maschine auf einem Host mit einem typischen Prozessor zu reproduzieren. Setzen Sie dazu das Limit auf:
- 25% - Welche in Bezug auf die Frequenz ~ 1350MHz
- 35% -1890 MHz
- 41% - 2214 MHz
- 65% - 3510 MHz
Die Anzahl der einmaligen Verbindungen wurde von 500 auf 1, 3, 5, 7 und 9 verringert.
Ergebnisse:
Verzögerungen:
TTFB wurde speziell als separater Test erstellt, da HTTPD Tools für jede einzelne Anforderung einen neuen Benutzer erstellt. Dieser Test ist immer noch weit von der Realität entfernt, da der Benutzer sowieso ein paar Seiten anklickt und in Wirklichkeit TTFP die Hauptrolle spielen wird.
Die erste, in der Regel die allererste Anforderung nach dem ersten Start der virtuellen Maschine, verarbeitet IIS durchschnittlich 120 ms.
Alle nachfolgenden Anforderungen zeigen einen TTFP von 1,5 ms. Apache und Nginx hinken hinterher. Persönlich betrachtet der Autor diesen Test als den aufschlussreichsten und würde einen Gewinner nur danach auswählen.
Das Ergebnis ist nicht überraschend, da IIS bereits komprimierten statischen Inhalt zwischenspeichert und ihn nicht bei jedem Zugriff einschränkt.
Zeit für einen Kunden
Um die Leistung zu bewerten, reicht ein Test mit einer einmaligen Verbindung aus.
Beispielsweise beendete IIS den Test mit einer Länge von 5.000 Benutzern in 40 Sekunden, was 123 Anforderungen pro Sekunde entspricht.
Die folgenden Grafiken zeigen die Zeit bis zur vollständigen Übertragung des Websiteinhalts. Dies ist der Prozentsatz der Anforderungen, die zu einem bestimmten Zeitpunkt abgeschlossen wurden. In unserem Fall wurden 80% aller Anforderungen in 8 ms auf IIS und in 4,5 ms auf Apache und Nginx verarbeitet, und 98% aller Anforderungen auf Apache und Nginx wurden innerhalb eines Intervalls von 8 Millisekunden ausgeführt.
Die Zeit, die für die Bearbeitung von 5000 Anfragen benötigt wurde:
Die Zeit, die für die Bearbeitung von 5000 Anfragen benötigt wurde:
Wenn Sie eine virtuelle Maschine mit einer 3,5-GHz-CPU und 8 Kernen haben, wählen Sie, was Sie wollen. Alle Webserver sind sich in diesem Test sehr ähnlich. Nachfolgend wird erläutert, welcher Webserver für jeden Host ausgewählt werden soll.
In einer etwas realeren Situation stehen sich alle Webserver gegenüber.
Durchsatz:
Zeitplan für Verzögerungen bei der Anzahl gleichzeitiger Verbindungen. Glatter und niedriger ist besser. Die letzten 2% wurden aus den Diagrammen geworfen, weil sie unleserlich werden würden.
Betrachten Sie nun die Option, bei der der Server auf einem gemeinsam genutzten Hosting gehostet wird. Nehmen Sie 4 Kerne bei 2,2 GHz und einen Kern bei 1,8 GHz.
Wie skaliere ich?
Wenn Sie jemals gesehen haben, wie die I - V-Eigenschaften von Elektrovakuum-Trioden, Pentoden usw. aussehen, sind Ihnen diese Diagramme vertraut. Das ist es, was wir zu fangen versuchen - Sättigung. Das Limit ist, wenn Sie nicht wie viele Kerne werfen, wird das Produktivitätswachstum nicht spürbar sein.
Bisher bestand die Herausforderung darin, 98% der Anfragen mit der geringsten Verzögerung aller Anfragen zu bearbeiten, um die Kurve so gleichmäßig wie möglich zu halten. Mit der Konstruktion einer anderen Kurve ermitteln wir nun für jeden Server den optimalen Arbeitspunkt.
Verwenden Sie dazu die Metrik Requests per Second (RPR). Horizontalfrequenz, vertikal - die Anzahl der pro Sekunde verarbeiteten Anforderungen, Zeilen - die Anzahl der Kerne.
Es wird eine Korrelation gezeigt, wie gut Nginx Anfragen nacheinander bearbeitet. 8 Kerne in solchen Tests zeigen sich besser.
Diese Grafik zeigt deutlich, wie viel besser (nicht viel) Nginx auf einem einzelnen Kern läuft. Wenn Sie über Nginx verfügen, sollten Sie erwägen, die Anzahl der Kerne auf einen zu reduzieren, wenn Sie nur Statik hosten.
Obwohl IIS laut DevTools in Chrome die niedrigste TTFB aufweist, gelingt es ihm, sowohl Nginx als auch Apache im ernsthaften Kampf gegen den Stresstest der Apache Foundation zu verlieren.
Die gesamte Krümmung der Graphen wird mit dem Zug reproduziert.
Eine Art Fazit:
Ja, Apache funktioniert auf Kernel 1 und 8 schlechter und auf 4 etwas besser.
Ja, Nginx auf 8 Kernen verarbeitet bessere Anforderungen nacheinander auf 1 und 4 Kernen und funktioniert schlechter, wenn viele Verbindungen bestehen.
Ja, IIS bevorzugt 4 Kerne für Multithread-Lasten und 8 Kerne für Singlethread. Am Ende war IIS auf 8 Kernen unter hoher Last etwas schneller als alle anderen, obwohl alle Server leer waren.
Dies ist kein Messfehler, der Fehler hier ist nicht mehr als + -1ms. in Verzögerungen und nicht mehr als + - 2-3 Anfragen pro Sekunde für RPR.
Die Ergebnisse sind nicht überraschend, wenn 8 Kerne schlechter sind. Viele Kerne und SMT / Hyperthreading verschlechtern die Leistung erheblich, wenn wir den Zeitrahmen haben, für den wir die gesamte Pipeline fertigstellen müssen.
Wir bieten einen aktualisierten UltraLite
Windows VDS- Tarif für 99 Rubel mit installiertem Windows Server 2019 Core an.
