V tomto článku si vyzkoušíme reverzní inženýrství, dalo by se říci. Dostaneme naše špinavé ruce pod kapotu každého webového serveru a zneužijeme je způsoby, které by nikdo nikdy nezneužil.
Tento test je měřením kulovitého koně ve vakuu, nic jiného než data, která byla získána, a my teď nevíme, co s tím dělat.
Metodologie
Operační systém pro Nginx a Apache je Ubuntu 18.04 LTS, pro IIS Windows Server Core 2019. Před testy všechny operační systémy obdržely nejnovější aktualizace k 04.12.2019. prosinci XNUMX.
Testy byly prováděny výhradně přes HTTP. Každý webový server provozoval stejnou stránku, bezplatnou šablonu Jekyll od Codrops.
Test propustnosti byl proveden pomocí nástrojů Httpd s argumenty:
ab -n 50000 -c 500 http://192.168.76.204:80/
Servery byly omezeny na 10, 5 a 1 procento jádra na 8, 4 a jednom jádru. Testovací stolicí byl počítač s frekvencí 9900K@5400MHz, což znamená, že server přijímající 10% limit přijímá přibližně 540MHz na jádro.
Test TTFB byl proveden při prvním spuštění serveru a změřen pomocí DevTools; po obdržení výsledku byl server vypnut a vrácen zpět k předchozímu kontrolnímu bodu, aby se eliminoval výskyt jakéhokoli druhu mezipaměti.
Tester a webový server byly na stejném hostiteli a na stejném virtuálním přepínači.
Chcete-li okamžitě vyhodnotit diskový subsystém, výsledky benchmarků ATTO a CrystalDIskMark, abyste měli představu o úzkých hrdlech.
Data stažená z virtuálního počítače:
Výsledky:
TTFB:
Průměrné TTFB pro IIS je nejmenší, 0,5 ms, oproti 1,4 ms pro Apache a 4 ms pro Nginx.
Propustnost:
Nejprve se podívejme, jak dobře se každý server škáluje na základě počtu jader.
Graf ukazuje počet volání testeru na webový server a latenci. Graf ukazuje, že NGINX zpracoval 98 % všech požadavků a doručil web za 20 ms nebo méně. IIS, stejně jako Apache, dokončilo posledních 5 % všech hovorů za 76 ms a 14 ms.
Graf ukazuje průměrnou dobu zpracování jednoho požadavku během zátěžového testu.
Jak můžete vidět z grafů, IIS odfouklo Apache i Nginx a při vysoké zátěži se výrazně zpomalilo.
IIS jasně preferovala 4 jádra před XNUMX, přičemž vykazovala nižší latence na XNUMX, ale také příliš neupřednostňovala jedno jádro.
NGINX se dobře škáluje napříč všemi 8 jádry a pro Apache se scénář s jedním jádrem zdá být nejlepší volbou.
Škálovatelnost:
Nginx:
Nyní se podíváme na škálovatelnost z hlediska frekvence a počtu jader.
Nginx neprošel testy s limitem 1 % pro 4 a 1 jádro, při překročení 2000 požadavků ukončil spojení s testerem.
Apache:
Apache, stejně jako Nginx, po zpracování 2500 požadavků vzdal a uzavřel připojení. Apache propadl v testu na 8, 4 a 1 jádrech s limitem 1 %, ale navíc propadl i v testu s limitem 5 % na jedno jádro, což je horší než Nginx
IIS:
Během testů IIS nashromáždila obrovskou frontu požadavků, ale zpracovala každý z nich. Zdá se, že po vybalení nejsou nastaveny žádné časové limity pro zpracování požadavku.
Graf ukazuje čas potřebný k dokončení testu. Zcela absurdní testovací konfigurace byly vyřazeny. Diagram ukazuje, jak náročný je IIS, pokud jde o hardware, a jak úžasný je NGINX.
Škálovatelnost z disku:
Nginx:
Nyní se podíváme na škálovatelnost z hlediska frekvence a počtu jader a rychlosti disku.
Tentokrát Nginx neuspěl ve 4 testech místo dvou.
Apache:
Apache selhal ve stejném počtu testů jako minule.
IIS:
IIS ukazuje téměř identický graf, jako by neexistovala žádná omezení disku. Obecně se grafika všech serverů příliš nezměnila, což znamená, že každý z nich ukládal statická data do paměti RAM a odtud je obsluhoval. Zde vidíme hlavní úzké hrdlo – samotný webový server.
Na závěry na základě tohoto testování je příliš brzy, zatím jsme HTTPS, kompresi a HTTP/2 netestovali živým certifikátem od Let's Encrypt. O tom si povíme v dalším článku.
Zdroj: www.habr.com