Bitwa serwerów WWW. Część 1 – oderwany od rzeczywistości HTTP:

W tym artykule spróbujemy swoich sił w inżynierii wstecznej. Zajrzymy naszymi brudnymi rękami pod maskę każdego z serwerów WWW, eksploatując je tak, jak nikt nigdy by ich nie eksploatował.

Ten test to pomiar sferycznego konia w próżni, to tylko dane, które zostały zebrane, a teraz nie wiemy, co z nimi zrobić.

Metodyka

Systemem operacyjnym dla Nginx i Apache jest Ubuntu 18.04 LTS, dla IIS - Windows Server Core 2019. Wszystkie systemy operacyjne przed testami zostały zaktualizowane do stanu z dnia 04.12.2019.

Testy były przeprowadzane wyłącznie przez HTTP. Na każdym z serwerów WWW była uruchomiona ta sama strona, darmowy szablon dla Jekyll od Codrops. Link. Na każdym z serwerów WWW wyłączono kompresję gzip.

Test przepustowości przeprowadzono za pomocą Httpd-tools z argumentami:

ab -n 50000 -c 500 http://192.168.76.204:80/

Na serwery nałożono limit 10%, 5% i 1% od rdzenia dla 8, 4 i jednego rdzenia. Jako stanowisko testowe użyto komputera z procesorem 9900K@5400 MHz, co oznacza, że serwer z limitem 10% otrzymuje około 540 MHz na rdzeń.

Test TTFB przeprowadzono przy pierwszym załadunku serwera, a wyniki mierzone były za pomocą DevTools. Po uzyskaniu wyniku serwer był wyłączany i przywracany do poprzedniego punktu kontrolnego, aby wykluczyć powstawanie jakichkolwiek pamięci podręcznych.

Tester i serwer WWW znajdowały się na tym samym hoście i na tym samym wirtualnym przełączniku.

Aby natychmiast ocenić system dyskowy, wyniki benchmarków ATTO i CrystalDiskMark, aby mieć pojęcie o wąskich gardłach.

Dane pobrane z maszyny wirtualnej:

Wyniki:

TTFB:

Średni TTFB dla IIS jest najniższy, wynosi 0,5 ms w porównaniu do 1,4 ms dla Apache i 4 ms dla Nginx.

Wydajność:

Najpierw przyjrzyjmy się, jak dobrze każdy z serwerów skaluje się względem liczby rdzeni.

Na wykresie przedstawiono liczbę zapytań testera do serwera WWW oraz opóźnienia. Na wykresie widać, że NGINX obsłużył 98% wszystkich zapytań, przekazując stronę w czasie 20 ms lub mniej. IIS, podobnie jak Apache, obsługiwał ostatnie 5% zapytań w czasie 76 ms i 14 ms odpowiednio.

Na wykresie przedstawiono średni czas przetwarzania jednego zapytania podczas testu obciążeniowego.

Jak można zauważyć na wykresach, IIS przegrał z Apache i Nginx, znacznie zwalniając pod dużym obciążeniem. 

IIS wyraźnie wolał 4 rdzenie zamiast ośmiu, pokazując mniejsze opóźnienia na czterech, ale również nie był zbyt zadowolony z jednego rdzenia.

NGINX doskonale skalowalny na wszystkie 8 rdzeni, natomiast dla Apache jednym rdzeniem wydaje się najlepszym wyborem.

Skalowalność:

Nginx:

Teraz rozważmy skalowalność pod kątem częstotliwości i liczby rdzeni. 

Testy z ograniczeniem wynoszącym 1% na 4 i 1 rdzeniu Nginx nie przeszedł, po przekroczeniu 2000 żądań przerywał połączenie z testerem.

Apache:

Apache podobnie jak Nginx przetwarzając 2500 żądań poddał się i przerwał połączenie. Apache nie przeszedł testu na 8, 4 i 1 rdzeniu z limitem 1%, ale oprócz tego nie przeszedł też testu przy 5% ograniczeniu na jednym rdzeniu, co jest gorsze niż Nginx.

IIS:

IIS podczas testów zebrał ogromną kolejkę żądań, ale przetworzył każde z nich. Wygląda na to, że nie ma w nim fabrycznie ustawionych limitów czasowych na przetwarzanie żądania.

Na diagramie przedstawiono czas, w którym zakończono test. Porzucono całkowicie absurdalne konfiguracje testowe. Z diagramu widać, jak bardzo IIS jest wymagający w odniesieniu do sprzętu, a jak doskonały jest NGINX.

Skalowalność dysku:

Nginx:

Teraz rozważmy skalowalność pod kątem częstotliwości, liczby rdzeni i prędkości dysku. 

Tym razem Nginx nie przeszedł 4 testów, zamiast dwóch.

Apache:

Apache oblał tę samą ilość testów, jak i poprzednio.

IIS:

IIS pokazuje niemal identyczny wykres, jakby nie było ograniczeń na dysk. Ogólnie rzecz biorąc, wykresy wszystkich serwerów nie zmieniły się znacznie, co oznacza, że każdy z nich przechowywał statykę w pamięci operacyjnej i dostarczał ją stamtąd. Tutaj widzimy główne wąskie miejsce – sam serwer WWW.

Wnioski na podstawie tych testów są przedwczesne, nie przetestowaliśmy jeszcze HTTPS, kompresji i HTTP/2 z aktywnym certyfikatem od Let’s Encrypt. O tym opowiemy w następnym artykule.

Źródło: habr.com