Ebben a cikkben megpróbáljuk magunkat a visszafejtésben, mondhatni. Minden webszerver burkolata alá fogjuk piszkos kezünket, és olyan módon aknázzuk ki őket, ahogyan azt soha senki nem használná ki.
Ez a teszt egy gömb alakú ló mérése vákuumban, nem más, mint a kapott adatok, és most nem tudjuk, mit kezdjünk vele.
technika
Az Nginx és az Apache operációs rendszere az Ubuntu 18.04 LTS, az IIS Windows Server Core 2019-hez. A tesztek előtt minden operációs rendszer megkapta a legújabb frissítéseket 04.12.2019. december XNUMX-én.
A teszteket kizárólag HTTP-n keresztül végezték. Mindegyik webszerver ugyanazt az oldalt futtatta, a Codrops ingyenes Jekyll sablonját. . Minden webszerveren le volt tiltva a gzip tömörítés.
Az áteresztőképesség-tesztet a Httpd-tools-szal végeztük el a következő argumentumokkal:
ab -n 50000 -c 500 http://192.168.76.204:80/A szerverek a mag 10, 5 és 1 százalékára korlátozódtak a 8, 4 és egy magon. A tesztpad egy 9900K@5400MHz-es számítógép volt, ami azt jelenti, hogy a 10%-os korlátot fogadó szerver magonként körülbelül 540 MHz-et kap.
A TTFB tesztet a szerver első indításakor végezték el, és DevTools segítségével mértek, az eredmény megérkezése után a szervert kikapcsolták, és visszaállították az előző ellenőrzőpontra, hogy kiküszöböljék a gyorsítótárak megjelenését.
A tesztelő és a webszerver ugyanazon a gazdagépen és ugyanazon a virtuális kapcsolón volt.
A lemez alrendszer azonnali értékeléséhez az ATTO és a CrystalDISkMark benchmark eredményeit, hogy képet kapjunk a szűk keresztmetszetekrõl.
A virtuális gépről vett adatok:
Eredmények:
TTFB:
Az IIS átlagos TTFB értéke a legkisebb, 0,5 ms, szemben az Apache 1,4 ms-mal és az Nginx 4 ms-mal.
Teljesítmény:
Először is nézzük meg, hogy az egyes szerverek mennyire skálázódnak a magok száma alapján.
A grafikon a webszerverhez intézett tesztelői hívások számát és a várakozási időt mutatja. A grafikon azt mutatja, hogy az NGINX az összes kérés 98%-át feldolgozta, és 20 ms vagy annál rövidebb idő alatt kézbesítette a webhelyet. Az IIS az Apache-hoz hasonlóan az összes hívás utolsó 5%-át 76 ms, illetve 14 ms alatt fejezte be.
A grafikon egy kérés átlagos feldolgozási idejét mutatja egy stresszteszt során.
Amint az a grafikonokon látható, az IIS lefújta az Apache-ot és az Nginx-et is, és nagy terhelés esetén jelentősen lelassult.
Az IIS egyértelműen előnyben részesítette a 4 magot a XNUMX helyett, alacsonyabb késleltetést mutatva a XNUMX magnál, de az egyik magot sem részesítette előnyben.
Az NGINX jól skálázható mind a 8 magra, és az Apache számára az egymagos forgatókönyv tűnik a legjobb választásnak.
Méretezhetőség:
nginx:
Most nézzük meg a méretezhetőséget a frekvencia és a magok száma szempontjából.
Az Nginx nem ment át a teszteken 1%-os korláttal 4 és 1 mag esetén, amikor meghaladta a 2000 kérést, megszakította a kapcsolatot a tesztelővel.
Apache:
Az Apache, akárcsak az Nginx, 2500 kérést feldolgozva feladta és lezárta a kapcsolatot. Az Apache 8, 4 és 1 magon 1%-os korláttal megbukott a teszten, de emellett egy magon 5%-os korláttal is megbukott, ami rosszabb, mint az Nginx
IIS:
A tesztek során az IIS óriási kéréseket halmozott fel, de mindegyiket feldolgozta. Úgy tűnik, hogy nincs beállítva időtúllépés a kérés feldolgozásához.
A diagram a teszt befejezéséhez szükséges időt mutatja. A teljesen abszurd tesztelési konfigurációkat elvetették. Az ábra azt mutatja, hogy az IIS mennyire igényes a hardver tekintetében, és milyen csodálatos az NGINX.
Méretezhetőség lemezről:
nginx:
Most nézzük meg a méretezhetőséget a frekvencia és a magok száma, valamint a lemez sebessége szempontjából.
Ezúttal az Nginx kettő helyett 4 teszten bukott meg.
Apache:
Az Apache ugyanannyi teszten bukott meg, mint legutóbb.
IIS:
Az IIS szinte azonos grafikont mutat, mintha nem lennének lemezkorlátozások. Általánosságban elmondható, hogy az összes szerver grafikája nem sokat változott, ami azt jelenti, hogy mindegyik a RAM-ban tárolta a statikus adatokat, és onnan szolgálta ki azokat. Itt látjuk a fő szűk keresztmetszetet - magát a webszervert.
A tesztelés alapján még korai következtetéseket levonni, még nem teszteltük a HTTPS-t, a tömörítést és a HTTP/2-t a Let's Encrypt élő tanúsítványával. Erről a következő cikkben fogunk beszélni.
Forrás: will.com