Ăber die Methode haben wir in einem Artikel erzĂ€hlt, in diesem testen wir HTTPS, aber in realistischeren Szenarien. FĂŒr den Test wurde ein Letâs Encrypt-Zertifikat erhalten und Brotli-Kompression auf 11 aktiviert.
Diesmal versuchen wir, das Szenario der Bereitstellung eines Servers auf VDS oder als virtuelle Maschine auf einem Host mit einem typischen Prozessor nachzubilden. Zu diesem Zweck haben wir eine Limitierung aufgestellt:
- 25 % â Das entspricht einer Frequenz von ~ 1350 MHz
- 35 % -1890 MHz
- 41 % â 2214 MHz
- 65 % â 3510 MHz
Die Anzahl gleichzeitiger Verbindungen wurde von 500 auf 1, 3, 5, 7 und 9 gesenkt,
Ergebnisse:
Latenzen:
TTFB wurde speziell als separates Testverfahren herausgehoben, da HTTPD Tools fĂŒr jede einzelne Anfrage quasi einen neuen Benutzer erstellt. Dieser Test ist weiterhin ausreichend von der RealitĂ€t entfernt, da der Benutzer trotzdem fĂŒr einige Seiten klicken wird und in der RealitĂ€t spielt TTFP die Hauptrolle.
Die erste, ĂŒberhaupt erste Anfrage nach dem Start der virtuellen Maschine IIS wird im Durchschnitt in 120 ms bearbeitet.
Alle nachfolgenden Anfragen zeigen ein TTFP von 1.5 ms. Bei Apache und Nginx ist das nicht der Fall. Der Autor selbst hĂ€lt diesen Test fĂŒr den aussagekrĂ€ftigsten und wĂŒrde den Gewinner nur danach wĂ€hlen.
Das Ergebnis ist nicht ĂŒberraschend, da IIS bereits komprimierte statische Inhalte zwischenlagert und sie nicht jedes Mal neu komprimiert, wenn darauf zugegriffen wird.
Zeit, die fĂŒr einen einzelnen Kunden aufgewendet wurde
FĂŒr die Leistungsbewertung reicht bereits 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 nachfolgenden Grafiken ist die Zeit bis zur vollstÀndigen Bereitstellung der Website-Inhalte dargestellt. Dies ist der Anteil der Anfragen, die zu einem bestimmten Zeitpunkt verarbeitet wurden. In unserem Fall wurden 80 % aller Anfragen in 8 ms auf IIS und in 4.5 ms auf Apache und Nginx bearbeitet, wÀhrend 98 % aller Anfragen auf Apache und Nginx im Intervall bis zu 8 Millisekunden bearbeitet wurden.
Die Zeit, die benötigt wurde, um 5000 Anfragen zu bearbeiten:
Die Zeit, die benötigt wurde, um 5000 Anfragen zu bearbeiten:
Wenn Sie eine virtuelle Maschine mit einem 3.5 GHz CPU und 8 Kernen haben, wĂ€hlen Sie, was Sie möchten. Alle Webserver sind in diesem Test sehr Ă€hnlich. DarĂŒber, welcher Webserver fĂŒr jeden Host ausgewĂ€hlt werden sollte, sprechen wir unten.
Wenn es um eine etwas realistischere Situation geht, sind alle Webserver gleichauf.
Durchsatz:
Grafik der Latenzen 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 machen wĂŒrden.
Jetzt betrachten wir die Option, bei der der Server auf einem virtuellen Hosting platziert wird. Nehmen wir 4 Kerne mit 2,2 GHz und einen Kern mit 1,8 GHz.
Wie skalieren
Wenn Sie jemals gesehen haben, wie die V-Ampel von Elektronenröhren, Pentoden usw. aussieht, werden Ihnen diese Grafiken vertraut sein. Genau das versuchen wir einzufangen â SĂ€ttigung. Die Grenze, an der es egal ist, wie viele Kerne Sie hinzufĂŒgen, der Anstieg der Leistung nicht mehr sichtbar ist.
FrĂŒher bestand die Herausforderung darin, 98% der Anfragen mit der geringsten Verzögerung fĂŒr alle Anfragen zu verarbeiten und die Kurve so gleichmĂ€Ăig wie möglich zu halten. Jetzt werden wir mit dem Aufbau einer anderen Kurve den optimalen Arbeitspunkt fĂŒr jeden der Server finden.
Dazu nehmen wir den Wert Requests per Second (RPR). Auf der horizontalen Achse die Frequenz, auf der vertikalen Achse die Anzahl der pro Sekunde verarbeiteten Anfragen, Linien â die Anzahl der Kerne.
Es wird gezeigt, wie gut Nginx Anfragen nacheinander bearbeitet. 8 Kerne zeigen in solchen Tests bessere Ergebnisse.
Auf diesem Diagramm ist klar 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 einen zu reduzieren, wenn Sie nur Statische Inhalte hosten.
Obwohl IIS laut DevTools in Chrome die niedrigste TTFB hat, schafft es dennoch, sowohl Nginx als auch Apache im ernsthaften Kampf gegen den Stresstest der Apache Foundation zu verlieren.
Die gesamte KrĂŒmmung der Grafiken wird zuverlĂ€ssig reproduziert.
Eine Art Fazit:
Ja, Apache funktioniert tatsÀchlich schlechter auf 1 und 8 Kernen, wÀhrend es auf 4 Kernen etwas besser lÀuft.
Ja, Nginx verarbeitet auf 8 Kernen Anfragen besser nacheinander, auf 1 und 4 Kernen jedoch schlechter, wenn es viele Verbindungen gibt.
Ja, IIS bevorzugt 4 Kerne fĂŒr Mehrfachbelastung und 8 Kerne fĂŒr Einzelbearbeitung. Letztendlich war IIS unter hoher Last auf 8 Kernen etwas schneller als alle anderen, obwohl alle Server relativ gleich waren.
Das ist kein Messfehler, die Abweichung liegt hier bei höchstens +-1 ms in der Verzögerung und nicht mehr als +-2-3 Anfragen pro Sekunde fĂŒr RPR.
Die Ergebnisse, wenn sich 8 Kerne schlechter verhalten, sind keineswegs ĂŒberraschend; viele Kerne und SMT/Hyperthreading verringern die Leistung erheblich, wenn wir zeitliche Rahmen haben, innerhalb derer wir den gesamten Pipeline-Abschluss erreichen mĂŒssen.
Quelle: habr.com
