O metodice jsme hovořili v článku, v tomto testujeme HTTPS, ale ve realistických scénářích. Pro testování byl získán certifikát Let’s Encrypt, aktivováno komprese Brotli na úrovni 11.
Tentokrát se pokusíme reprodukovat scénář nasazení serveru na VDS nebo jako virtuální stroj na hostitelském serveru s běžným procesorem. Pro tento účel byl nastaven limit na:
- 25 % — což odpovídá frekvenci ~ 1350 MHz
- 35 % - 1890 MHz
- 41 % — 2214 MHz
- 65 % — 3510 MHz
Počet simultánních připojení byl snížen z 500 na 1, 3, 5, 7 a 9,
Výsledky:
Zpoždění:
TTFB byl speciálně vyčleněn jako samostatný test, protože HTTPD Tools pro každý jednotlivý požadavek vytváří jakoby nového uživatele. Tento test je stále dost vzdálen od reality, protože uživatel by nakonec kliknul na pár stránek a v realitě hraje hlavní roli TTFP.
První, zcela první požadavek po prvním spuštění virtuálního stroje IIS se vyřizuje průměrně za 120 ms.
Všechny následující požadavky vykazují TTFP ve 1,5 ms. Apache a Nginx v tom zaostávají. Osobně autor považuje tento test za nejvýznamnější a vybíral by vítěze jen na jeho základě.
Výsledek není překvapující, protože IIS ukládá již komprimovaný statický obsah do cache a znovu ho nekontroluje při každém přístupu.
Čas vynaložený na jednoho klienta
Pro hodnocení výkonnosti stačí i test s 1 simultánním připojením.
Například, IIS dokončil testování s 5000 uživateli za 40 sekund, což představuje 123 požadavků za sekundu.
V grafech níže je uveden čas do úplného přenosu obsahu webu. To je podíl požadavků vyřízených v určitém čase. V našem případě bylo 80 % všech požadavků zpracováno za 8 ms na IIS a za 4,5 ms na Apache a Nginx, a interval do 8 milisekund byl splněn 98 % všech požadavků na Apache a Nginx.
Čas, za který bylo zpracováno 5000 požadavků:
Čas, za který bylo zpracováno 5000 požadavků:
Pokud máte virtuální stroj s 3,5 GHz CPU a 8 jádry, vyberte si, co chcete. Všechny webové servery jsou si v tomto testování velmi podobné. O tom, který webový server vybrat pro každý host, budeme hovořit níže.
Když jde o o něco reálnější situaci, všechny webové servery jdou nos k nos.
Průchodnost:
Graf zpoždění v závislosti na počtu simultánních připojení. Rovnější a nižší – lepší. Poslední 2 % byly vyřazeny z grafů, protože by je učinily nečitelnými.
Nyní se podíváme na variantu, kde je server umístěn na virtuálním hostingu. Vezmeme 4 jádra běžící na 2,2 GHz a jedno jádro na 1,8 GHz.
Jak se škáluje
Pokud jste někdy viděli, jak vypadají grafy I-V elektronek, pentod a tak dále, tyto grafy vám budou známé. Tento efekt se snažíme zachytit - nasycení. Hranice, kdy ať už přidáte jakkoliv mnoho jader, nárůst výkonu nebude patrný.
Dříve byla celá výzva v tom, zpracovat 98 % požadavků s co nejnižší latencí, jak nejrovnoměrněji držet křivku. Nyní pomocí další křivky najdeme optimální pracovní bod pro každý server.
K tomu vezmeme ukazatel Requests per second (RPR). Na horizontální ose je frekvence, na vertikální - počet požadavků zpracovaných za sekundu, čáry - počet jader.
Ukazuje se korelace, jak dobře Nginx zpracovává požadavky jeden po druhém. 8 jader se v takovém testování ukázalo lépe.
Na tomto grafu je jasně vidět, jak lépe (ne o moc) Nginx funguje na jednom jádru. Pokud používáte Nginx, stojí za úvahu snížit počet jader na jedno, pokud hostujete pouze statiku.
IIS, ačkoliv má podle DevTools v Chromu nejnižší TTFB, se nemůže měřit s Nginx ani Apaché v intenzivním stresovém testu od Apache Foundation.
Celá křivost grafů se reprodukuje přesně.
Druhou závěrem:
Ano, Apache funguje jednoznačně hůře na 1 a 8 jádrech, a na 4 funguje o něco lépe.
Ano, Nginx na 8 jádrech lépe zpracovává požadavky jeden po druhém, na 1 a 4 jádrech a hůře funguje při vysokém počtu připojení.
Ano, IIS preferuje 4 jádra pro vícevláknové zatížení a 8 jader pro jednovláknové. Nakonec se IIS ukázal být o něco rychlejší na 8 jádrech při vysokém zatížení, ačkoliv všechny servery fungovaly podobně.
To není chyba měření, odchylka zde není větší než +-1 ms v latencích a ne více než +-2-3 požadavky za sekundu pro RPR.
Výsledky, kdy 8 jader vykazují horší výkon, nejsou překvapující, mnoho jader a SMT/Hyperthreading výrazně zhoršují výkon, pokud máme časové rámce, za které musíme dokončit celý pipeline.
Zdroj: habr.com
