O metodzie opowiadaliśmy w artykułach, w tej testujemy HTTPS, ale w bardziej realistycznych scenariuszach. Do testowania uzyskano certyfikat Let’s Encrypt, włączono kompresję Brotli na 11.
Tym razem spróbujemy odtworzyć scenariusz wdrożenia serwera na VDS lub jako maszyny wirtualnej na hostingu z typowym procesorem. W tym celu nałożono limit:
- 25% – co w przeliczeniu na częstotliwość ~ 1350 MHz
- 35% - 1890 MHz
- 41% – 2214 MHz
- 65% – 3510 MHz
Liczba jednoczesnych połączeń została zmniejszona z 500 do 1, 3, 5, 7 i 9,
Wyniki:
Opóźnienia:
TTFB został specjalnie wyróżniony jako osobny test, ponieważ HTTPD Tools dla każdego pojedynczego zapytania tworzy jakby nowego użytkownika. Ten test wciąż jest dość oderwany od rzeczywistości, ponieważ użytkownik i tak kliknie na kilka stron, a w rzeczywistości kluczową rolę odegra TTFP.
Pierwsze, w ogóle pierwsze zapytanie po pierwszym uruchomieniu maszyny wirtualnej IIS realizuje średnio w ciągu 120 ms.
Wszystkie kolejne zapytania pokazują TTFP na poziomie 1.5 ms. Apache i Nginx w tym odstają. Autor osobiście uważa ten test za najbardziej reprezentatywny i wybierałby zwycięzcę tylko na jego podstawie.
Wynik nie jest zaskakujący, ponieważ IIS buforuje już skompresowaną zawartość statyczną i nie kompresuje jej ponownie za każdym razem, gdy jest to wymagane.
Czas poświęcony na jednego klienta
Aby ocenić wydajność, wystarczy test z 1 jednoczesnym połączeniem.
Na przykład, IIS zakończył testowanie z 5000 użytkowników w ciągu 40 sekund, co daje 123 zapytań na sekundę.
Na poniższych wykresach przedstawiono czas do pełnego przesłania treści strony. To odsetek zapytań, które zostały zrealizowane w określonym czasie. W naszym przypadku 80% wszystkich zapytań zostało przetworzonych w ciągu 8 ms na IIS i 4.5 ms na Apache i Nginx, a interwał do 8 milisekund zrealizowało 98% wszystkich zapytań na Apache i Nginx.
Czas, w którym przetworzono 5000 zapytań:
Czas, w którym przetworzono 5000 zapytań:
Jeśli masz maszynę wirtualną z CPU 3.5 GHz i 8 rdzeniami, wybierz to, co chcesz. Wszystkie serwery WWW są bardzo podobne w tym teście. O tym, który serwer WWW wybrać dla każdego hosta, porozmawiamy poniżej.
Gdy mówimy o nieco bardziej realistycznej sytuacji, wszystkie serwery WWW idą łeb w łeb.
Wydajność:
Wykres opóźnień w zależności od liczby jednoczesnych połączeń. Im bardziej równy i niższy, tym lepiej. Ostatnie 2% zostało usuniętych z wykresów, ponieważ uczyniłyby je nieczytelnymi.
Teraz rozważmy opcję, w której serwer znajduje się na hostingu wirtualnym. Weźmiemy 4 rdzenie po 2,2 GHz i jeden rdzeń o częstotliwości 1,8 GHz.
Jak się skalują
Jeśli kiedykolwiek widzieliście, jak wyglądają charakterystyki statyczne triody i pentody, te wykresy będą dla was znajome. To właśnie próbujemy uchwycić – nasycenie. Granicę, kiedy niezależnie od liczby rdzeni, wzrost wydajności nie będzie znaczący.
Wcześniej cały challenge polegał na przetworzeniu 98% zapytań z możliwie najniższym opóźnieniem, aby jak najrówniej utrzymać krzywą. Teraz z pomocą innej krzywej znajdziemy optymalny punkt roboczy dla każdego z serwerów.
W tym celu weźmiemy wskaźnik Requests per second (RPR). Po osi poziomej - częstotliwość, po osi pionowej - liczba zapytań przetworzonych na sekundę, linie - liczba rdzeni.
Pokazuje to korelację, jak dobrze Nginx przetwarza zapytania jedno po drugim. 8 rdzeni w takim teście wypada lepiej.
Na tym wykresie doskonale widać, jak lepiej (nieznacznie) Nginx działa na jednym rdzeniu. Jeśli używasz Nginx, warto rozważyć zmniejszenie liczby rdzeni do jednego, jeśli hostujesz tylko statykę.
IIS, chociaż ma najniższy TTFB według DevTools w Chrome, udaje się przegrać z Nginx i Apache w poważnej walce z testem obciążeniowym od Apache Foundation.
Cała krzywizna wykresów jest reprodukowana nieskazitelnie.
Rodzaj podsumowania:
Tak, Apache zdecydowanie działa gorzej na 1 i 8 rdzeniach, a na 4 wypada nieco lepiej.
Tak, Nginx na 8 rdzeniach lepiej przetwarza zapytania jedno po drugim, a na 1 i 4 rdzeniach działa gorzej, gdy jest dużo połączeń.
Tak, IIS preferuje 4 rdzenie dla obciążenia wielowątkowego i 8 rdzeni dla obciążenia jednowątkowego. Ostatecznie IIS okazał się nieco szybszy od innych na 8 rdzeniach przy dużym obciążeniu, chociaż wszystkie serwery były na równi.
To nie jest błąd pomiaru, niepewność wynosi nie więcej niż ±1 ms w opóźnieniach i nie więcej niż ±2-3 zapytań na sekundę dla RPR.
Wyniki, w których 8 rdzeni wypada gorzej, wcale nie są zaskakujące, wiele rdzeni i SMT/Hyperthreading znacznie pogarszają wydajność, jeśli mamy ramy czasowe, w których musimy zakończyć cały pipeline.
Źródło: habr.com
