V tomto článku se pokusíme o reverzní inženýrství, dá se říct. Nahlédneme našimi špinavými rukama pod kapotu každého z webových serverů a využijeme je tak, jak by je nikdo jiný nikdy nevyužil.
Tento test je měřením sférického koně ve vakuu, jsou to jen data, která byla získána, a nyní nevíme, co s nimi dělat.
Metodika
Jako operační systém pro Nginx a Apache slouží Ubuntu 18.04 LTS, pro IIS Windows Server Core 2019. Všechny operační systémy před testy dostaly poslední aktualizace k datu 04.12.2019.
Testy byly prováděny výhradně po HTTP. Na každém z webových serverů běžela stejná stránka, zdarma dostupná šablona pro Jekyll od Codrops. . Na každém z webových serverů bylo vypnuto komprese gzip.
Test propustnosti byl prováděn s Httpd-tools s argumenty:
ab -n 50000 -c 500 http://192.168.76.204:80/Na servery byl nastaven limit 10, 5 a 1 procento od jádra na 8, 4 a jednom jádře. Testovací stanice byla počítač s 9900K@5400MHz, což znamená, že server, který dostal omezení 10%, získává přibližně 540MHz na jádro.
Test TTFB byl proveden při prvním načtení serveru a měřil se pomocí DevTools, po získání výsledku byl server vypnut a vrácen na předchozí kontrolní bod, aby se vyloučila jakákoliv forma cache.
Tester a webový server byly na stejném hostiteli a na stejném virtuálním přepínači.
Abychom hned vyhodnotili diskový subsystém, výsledky benchmarků ATTO a CrystalDIskMark, abychom měli představu o úzkých místech.
Data byla získána z virtuálního stroje:
Výsledky:
TTFB:
Průměrný TTFB u IIS je nejnižší, 0,5ms, oproti 1,4ms u Apache a 4ms u Nginx.
Průchodnost:
Nejprve se podíváme, jak dobře se každý ze serverů škáluje podle počtu jader.
Na grafu je znázorněn počet požadavků testujícího na webový server a latence. Na grafu je vidět, že NGINX zpracoval 98% všech požadavků a poskytl stránku za 20ms a méně. IIS, stejně jako Apache, zpracoval posledních 5% ze všech požadavků za 76ms a 14ms respektive.
Na grafu je znázorněn průměrný čas zpracování jednoho požadavku během zátěžového testu.
Jak je možné vidět z grafů, IIS prohrál s oběma, Apache a Nginx, značně zpomalil při vysoké zátěži.
IIS očividně preferoval 4 jádra před osmi, vykazoval menší latenci na čtyřech, ale také příliš neschvaloval ani jedno jádro.
NGINX se skvěle škáluje na všech 8 jádrech, zatímco pro Apache se zdá, že jednojádrový scénář je tím nejlepším řešením.
Škálovatelnost:
Nginx:
Nyní se podíváme na škálovatelnost podle frekvence a počtu jader.
Testy s omezením na 1% na 4 a 1 jádru Nginx neprošel, po překročení 2000 požadavků přerušil spojení s testerem.
Apache:
Apache, stejně jako Nginx, po zpracování 2500 požadavků vzdal a přerušil spojení. Apache neprošel testem na 8, 4 a 1 jádru s limitem 1%, navíc neprošel ani testem s 5% omezením na jednom jádru, což je horší než Nginx.
IIS:
IIS během testů vytvořil obrovskou frontu požadavků, ale zpracoval každý z nich. Zřejmě v něm není standardně nastaven timeout pro zpracování požadavku.
Na diagramu je znázorněn čas, za který byl test dokončen. Byly vyloučeny zcela absurdní konfigurace testování. Z diagramu je vidět, jak velmi IIS vyžaduje hardware a jak vynikající je NGINX.
Škálovatelnost podle disku:
Nginx:
Nyní se podíváme na škálovatelnost podle frekvence, počtu jader a rychlosti disku.
Tentokrát Nginx neprošel 4 testy, místo dvou.
Apache:
Apache selhal v rámci stejného počtu testů jako naposledy.
IIS:
IIS ukazuje téměř identický graf, jako by žádné omezení na disk neexistovalo. Celkově se grafy všech serverů moc nezměnily, což znamená, že každý z nich si uchoval statiku v operační paměti a poskytoval ji odtud. Zde vidíme hlavní úzké místo – samotný webový server.
Je příliš brzy na to, abychom vyvodili závěry z tohoto testování, ještě jsme netestovali HTTPS, kompresi a HTTP/2 s živým certifikátem od Let’s Encrypt. O tom budeme hovořit v dalším článku.
Zdroj: habr.com
