Ebben a cikkben megpróbáljuk a reverz mérnökséget, mondhatni. Megleshetjük, hogy mi történt a webkiszolgálók motorháztetője alatt, kihasználva őket, ahogyan senki más nem tenné.
Ez a teszt egy gömb alakú ló mérése a vákuumban, csupán adatok, amelyeket megkaptunk, és most már nem tudjuk, mit kezdjünk velük.
Módszertan
Az Nginx és Apache operációs rendszere az Ubuntu 18.04 LTS, míg az IIS a Windows Server Core 2019. Minden operációs rendszert a tesztek előtt a 2019.12.04-i állapotnak megfelelően frissítettek.
A teszteket kizárólag HTTP-n végezték. Minden webkiszolgálón ugyanaz az oldal futott, a Codrops ingyenes Jekyll sablonja. . Minden webkiszolgálón le volt tiltva a gzip tömörítés.
A sávszélesség tesztjét a Httpd-tools segítségével végeztük az alábbi argumentumokkal:
ab -n 50000 -c 500 http://192.168.76.204:80/A szerverekre 10, 5 és 1 százalékos korlát került beállításra a 8, 4 és 1 magra. A tesztkörnyezet egy 9900K@5400MHz számítógép volt, ami azt jelenti, hogy a 10%-os korlátot kapott szerver körülbelül 540 MHz-t kap egy magra.
A TTFB teszt a szerver első betöltésekor zajlott, és a DevTools segítségével mérték. Az eredmény megérkezése után a szerver kikapcsolt, és visszaváltozott a korábbi ellenőrzési pontra, hogy kizárjuk bármilyen fajta gyorsítótár megjelenését.
A tesztelő és a webkiszolgáló ugyanazon a hoszton és ugyanazon a virtuális kapcsolón helyezkedtek el.
Annak az azonnali értékelésére, hogy a lemezes alrendszer hogyan teljesít, az ATTO és a CrystalDiskMark benchmark eredmények, hogy legyen elképzelésünk a szűk keresztmetszetekről.
Az adatok a virtuális gépről származnak:
Results:
TTFB:
Az IIS átlagos TTFB-je a legalacsonyabb, 0,5 ms, míg az Apache 1,4 ms-t, a Nginx pedig 4 ms-t mér.
Átviteli sebesség:
Először nézzük meg, mennyire jól skálázódnak a szerverek a magok számát tekintve.
A grafikonon a tesztelő webkiszolgálóhoz intézett kéréseinek száma és a késleltetés látható. A grafikon alapján az NGINX a kérdések 98%-át kezelte, a weboldalt 20 ms-nál kevesebb idő alatt adta át. Az IIS és az Apache a kérdések utolsó 5%-át 76 ms és 14 ms alatt kezelte.
A grafikonon a stresszteszt során egyetlen kérés feldolgozásának átlagos ideje látható.
Ahogyan a grafikonokból is látszik, az IIS vereséget szenvedett mind az Apache, mind a Nginx ellen, jelentősen lelassulva a nagy terhelés alatt.
Az IIS egyértelműen a 4 magot részesítette előnyben a nyolccal szemben, kisebb késleltetéseket mutatva a négy mag esetén, de az egy maggal is csak kicsit volt elégedett.
Az NGINX tökéletesen skálázódik a 8 magra, míg az Apache számára egy magos forgatókönyv tűnik a legjobb választásnak.
Skálázhatóság:
Nginx:
Most nézzük meg a skálázhatóságot a magok számának és frekvenciájának függvényében.
Az 1%-os korlátozással végzett tesztben a 4 és 1 magos Nginx nem teljesített, 2000 kérés felett megszakította a kapcsolatot a tesztelővel.
Apache:
Az Apache, mint a Nginx, 2500 kérés után feladta és megszakította a kapcsolatot. Az Apache nem teljesítette a tesztet 8, 4 és 1 magos konfigurációval 1%-os korlátozással, sőt, a 1 magos, 5%-os tesztet is elbukta, ami rosszabb, mint a Nginx teljesítménye.
IIS:
Az IIS a tesztek során hatalmas sorozatot gyűjtött össze a kérésekből, de mindegyiket feldolgozta. Úgy tűnik, hogy alapértelmezetten nincsenek beállítva időkorlátok a kérések feldolgozására.
A diagram bemutatja azt az időt, amely alatt a teszt befejeződött. Teljesen abszurd tesztelési konfigurációkat elhagytak. A diagramon látható, hogy az IIS mennyire igényes a hardverre és mennyire kiváló a NGINX.
Skálázhatóság lemez alapján:
Nginx:
Most nézzük meg a skálázhatóságot a magok számának, frekvenciájának és a lemez sebességének függvényében.
Ezúttal az Nginx nem teljesítette a 4 tesztet, helyette kettőt.
Apache:
Az Apache ugyanolyan számú tesztet bukott el, mint legutóbb.
IIS:
Az IIS szinte azonos grafikont mutat, mintha nem lettek volna korlátozások a lemezen. Összességében a szerverek grafikája nem változott jelentősen, ami azt jelenti, hogy mindegyikük a statikus tartalmat a memóriába cache-elte és onnan szolgálta ki. Itt látjuk a legfőbb szűk keresztmetszetet – maga a webkiszolgáló.
Túl korai következtetéseket levonni ebből a tesztelésből, még nem teszteltük a HTTPS-t, a tömörítést és a HTTP/2-t az élő Let’s Encrypt tanúsítvánnyal. Erről a következő cikkben számolunk be.
Forrás: habr.com
