Povídali jsme si o technice V tomto článku testujeme HTTPS, ale v realističtějších scénářích. Pro testování jsme získali certifikát Let's Encrypt a povolili Brotli kompresi na 11.
Tentokrát se pokusíme reprodukovat scénář nasazení serveru na VDS nebo jako virtuální stroj na hostiteli se standardním procesorem. Pro tento účel byl stanoven limit:
- 25 % - Což odpovídá frekvenci ~ 1350 MHz
- 35% -1890MHz
- 41 % - 2214 MHz
- 65 % - 3510 MHz
Počet jednorázových spojení byl snížen z 500 na 1, 3, 5, 7 a 9,
Výsledky:
Zpoždění:
TTFB byl specificky zahrnut jako samostatný test, protože HTTPD Tools vytváří nového uživatele pro každý jednotlivý požadavek. Tento test je zatím dost odtržený od reality, protože uživatel si stejně proklikne pár stránek a v reálu bude hrát hlavní roli TTFP.
První, obecně úplně první požadavek po prvním spuštění virtuálního stroje IIS trvá v průměru 120 ms.
Všechny následující požadavky ukazují TTFP 1.5 ms. Apache a Nginx v tomto ohledu zaostávají. Osobně považuje autor tento test za nejvíce objevný a vítěze by vybral až podle něj.
Výsledek není překvapivý, protože služba IIS ukládá do mezipaměti již komprimovaný statický obsah a nekomprimuje jej při každém přístupu.
Čas strávený na klienta
Pro vyhodnocení výkonu stačí test s 1 jediným připojením.
Například IIS dokončila test 5000 uživatelů za 40 sekund, což je 123 požadavků za sekundu.
Níže uvedené grafy ukazují dobu do úplného přenesení obsahu webu. Jedná se o podíl požadavků dokončených v dané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 8 % všech požadavků na Apache a Nginx bylo dokončeno v intervalu do 98 milisekund.
Doba, během které bylo zpracováno 5000 žádostí:
Doba, během které bylo zpracováno 5000 žádostí:
Pokud máte virtuální stroj s 3.5 GHz CPU a 8 jádry, vyberte si, co chcete. Všechny webové servery jsou v tomto testování velmi podobné. O tom, který webový server vybrat pro jednotlivé hostitele, si povíme níže.
Když dojde na trochu realističtější situaci, všechny webové servery si jdou po krku.
Propustnost:
Graf zpoždění versus počet souběžných spojů. Hladší a nižší je lepší. Poslední 2 % byly z grafů odstraněny, protože by byly nečitelné.
Nyní se podívejme na možnost, kdy je server hostován na virtuálním hostingu. Vezměme 4 jádra na 2.2 GHz a jedno jádro na 1.8 GHz.
Jak škálovat
Pokud jste někdy viděli, jak vypadají proudově-napěťové charakteristiky vakuových triod, pentod a tak dále, budou vám tyto grafy povědomé. Toho se snažíme chytit – saturace. Limit je, když bez ohledu na to, kolik jader hodíte, zvýšení výkonu nebude patrné.
Dříve bylo celým úkolem zpracovat 98 % požadavků s nejnižší latencí pro všechny požadavky a udržet křivku co nejplošší. Nyní sestrojením další křivky najdeme optimální provozní bod pro každý ze serverů.
Chcete-li to provést, vezměme indikátor požadavků za sekundu (RPR). Horizontální je frekvence, vertikální je počet zpracovaných požadavků za sekundu, řádky jsou počet jader.
Ukazuje korelaci toho, jak dobře Nginx zpracovává požadavky jeden po druhém. 8 jader si v tomto testu vede lépe.
Tento graf jasně ukazuje, o kolik lépe (ne moc) funguje Nginx na jediném jádru. Pokud máte Nginx, měli byste zvážit snížení počtu jader na jedno, pokud hostujete pouze statická.
IIS, přestože má nejnižší TTFB podle DevTools v Chrome, dokáže ve vážném boji se zátěžovým testem od Apache Foundation prohrát s Nginxem i Apache.
Veškeré zakřivení grafů je reprodukováno železem.
Nějaký závěr:
Ano, Apache funguje hůře na 1 a 8 jádrech, ale na 4 funguje o něco lépe.
Ano, Nginx na 8 jádrech zpracovává požadavky lépe jeden po druhém, na 1 a 4 jádrech, a funguje hůře, když je mnoho připojení.
Ano, IIS preferuje 4 jádra pro vícevláknové úlohy a preferuje 8 jader pro jednovláknové úlohy. IIS byl nakonec o něco rychlejší než všichni ostatní na 8 jádrech pod vysokým zatížením, ačkoli všechny servery byly na stejné úrovni.
Nejedná se o chybu měření, chyba zde není větší než +-1 ms. ve zpožděních a ne více než +- 2-3 požadavky za sekundu pro RPR.
Výsledky, kdy 8 jader funguje hůře, nejsou vůbec překvapivé, mnoho jader a SMT/Hyperthreading výkon značně degraduje, pokud máme časový rámec, ve kterém musíme dokončit celý pipeline.
Zdroj: www.habr.com