Rozmawialiśmy o metodologii w artykule, w tym testujemy HTTPS, ale w bardziej realistycznych scenariuszach. Do testów uzyskaliśmy certyfikat Let's Encrypt i włączyliśmy kompresję Brotli do 11.
Tym razem spróbujemy odtworzyć scenariusz wdrożenia serwera na VDS lub jako maszyna wirtualna na hoście ze standardowym procesorem. W tym celu ustalono limit na poziomie:
- 25% - co odpowiada częstotliwości ~ 1350 MHz
- 35% -1890 MHz
- 41% - 2214 MHz
- 65% - 3510 MHz
Zmniejszono liczbę jednorazowych połączeń z 500 do 1, 3, 5, 7 i 9,
Wyniki:
Opóźnienia:
TTFB został specjalnie uwzględniony jako oddzielny test, ponieważ narzędzia HTTPD tworzą nowego użytkownika dla każdego indywidualnego żądania. Test ten jest jeszcze dość oderwany od rzeczywistości, bo użytkownik i tak kliknie kilka stron, a tak naprawdę główną rolę będzie odgrywać TTFP.
Pierwsze, generalnie pierwsze żądanie po pierwszym uruchomieniu maszyny wirtualnej IIS trwa średnio 120 ms.
Wszystkie kolejne żądania wykazują TTFP wynoszące 1.5 ms. Apache i Nginx pozostają pod tym względem w tyle. Osobiście autor uważa ten test za najbardziej odkrywczy i dopiero na jego podstawie wyłoniłby zwycięzcę.
Wynik nie jest zaskakujący, ponieważ IIS buforuje już skompresowaną zawartość statyczną i nie kompresuje jej przy każdym dostępie.
Czas spędzony na jednego klienta
Aby ocenić wydajność, wystarczy test z 1 pojedynczym połączeniem.
Na przykład usługi IIS ukończyły test 5000 użytkowników w 40 sekund, co oznacza 123 żądania na sekundę.
Poniższe wykresy przedstawiają czas do całkowitego przeniesienia zawartości witryny. Jest to odsetek wniosków zrealizowanych w danym czasie. W naszym przypadku 80% wszystkich żądań zostało przetworzonych w 8 ms na IIS i 4.5 ms na Apache i Nginx, a 8% wszystkich żądań na Apache i Nginx zostało zrealizowanych w przedziale do 98 milisekund.
Czas, w którym przetworzono 5000 żądań:
Czas, w którym przetworzono 5000 żądań:
Jeśli masz maszynę wirtualną z procesorem 3.5 GHz i 8 rdzeniami, wybierz, co chcesz. Wszystkie serwery internetowe są bardzo podobne w tym teście. Poniżej porozmawiamy o tym, który serwer WWW wybrać dla każdego hosta.
Jeśli chodzi o nieco bardziej realistyczną sytuację, wszystkie serwery internetowe idą łeb w łeb.
Wydajność:
Wykres opóźnień w funkcji liczby jednoczesnych połączeń. Gładko i niżej tym lepiej. Ostatnie 2% usunięto z wykresów, gdyż czyniłyby je nieczytelnymi.
Rozważmy teraz opcję, w której serwer jest hostowany na hostingu wirtualnym. Weźmy 4 rdzenie o częstotliwości 2.2 GHz i jeden rdzeń o częstotliwości 1.8 GHz.
Jak skalować
Jeśli kiedykolwiek widziałeś, jak wyglądają charakterystyki prądowo-napięciowe triod próżniowych, pentod itp., te wykresy będą ci znane. To właśnie staramy się uchwycić – nasycenie. Limit polega na tym, że niezależnie od liczby rdzeni, wzrost wydajności nie będzie zauważalny.
Wcześniej całym wyzwaniem było przetworzenie 98% żądań przy jak najniższym opóźnieniu dla wszystkich żądań i utrzymaniu możliwie płaskiej krzywej. Teraz konstruując kolejną krzywą znajdziemy optymalny punkt pracy dla każdego z serwerów.
Aby to zrobić, weźmy wskaźnik żądań na sekundę (RPR). Pozioma to częstotliwość, pionowa to liczba żądań przetwarzanych na sekundę, linie to liczba rdzeni.
Pokazuje korelację tego, jak dobrze Nginx przetwarza żądania jedno po drugim. W tym teście 8 rdzeni radzi sobie lepiej.
Ten wykres wyraźnie pokazuje, o ile lepiej (niewiele) Nginx działa na jednym rdzeniu. Jeśli masz Nginx, powinieneś rozważyć zmniejszenie liczby rdzeni do jednego, jeśli hostujesz tylko statyczne.
IIS, choć ma najniższy TTFB według DevTools w Chrome, udaje mu się przegrać zarówno z Nginxem, jak i Apache w poważnej walce z stress testem od Apache Foundation.
Cała krzywizna wykresów jest odwzorowana w żelaznej formie.
Jakiś wniosek:
Tak, Apache działa gorzej na 1 i 8 rdzeniach, ale działa trochę lepiej na 4.
Tak, Nginx na 8 rdzeniach lepiej przetwarza żądania jeden po drugim, na 1 i 4 rdzeniach, a gorzej przy dużej liczbie połączeń.
Tak, usługi IIS preferują 4 rdzenie w przypadku obciążeń wielowątkowych i preferują 8 rdzeni w przypadku obciążeń jednowątkowych. Ostatecznie usługi IIS były nieco szybsze niż wszystkie inne na 8 rdzeniach przy dużym obciążeniu, chociaż wszystkie serwery działały na równi.
Nie jest to błąd pomiaru, błąd tutaj nie przekracza +-1ms. z opóźnieniami i nie więcej niż +- 2-3 żądań na sekundę w przypadku RPR.
Wyniki, w których 8 rdzeni radzi sobie gorzej, wcale nie są zaskakujące, wiele rdzeni i SMT/Hyperthreading znacznie pogarszają wydajność, jeśli mamy ramy czasowe, w których musimy ukończyć cały potok.
Źródło: www.habr.com