În acest articol, vom încerca să ne aventurăm în ingineria inversă, să spunem. Ne vom uita cu mâinile murdare sub capota fiecărui server web, exploatându-le așa cum nimeni nu ar face-o vreodată.
Acest test este măsurarea unui cal sferic în vid, nu mai mult decât datele care au fost obținute, și acum nu știm ce să facem cu ele.
Metodologia
Pentru Nginx și Apache, sistemul de operare utilizat este Ubuntu 18.04 LTS, iar pentru IIS, Windows Server Core 2019. Toate sistemele de operare au primit ultimele actualizări înainte de testare, la data de 04.12.2019.
Testele au fost efectuate exclusiv prin HTTP. Pe fiecare dintre serverele web rula aceeași pagină, un șablon gratuit pentru Jekyll de la Codrops. . Pe fiecare dintre serverele web a fost dezactivată compresia gzip.
Testul de lățime de bandă a fost efectuat cu Httpd-tools cu argumentele:
ab -n 50000 -c 500 http://192.168.76.204:80/Serverele au fost limitate la 10%, 5% și 1% din CPU pe 8, 4 și, respectiv, un nucleu. Ca banc de testare, a fost folosit un computer cu 9900K@5400MHz, ceea ce înseamnă că serverul cu limita de 10% primește aproximativ 540MHz pe nucleu.
Testul TTFB a fost efectuat la prima încărcare a serverului și a fost măsurat cu ajutorul DevTools, după obținerea rezultatului, serverul a fost oprit și restaurat la punctul de control anterior, pentru a exclude apariția oricărui tip de cache.
Testerul și serverul web se aflau pe același host și pe același switch virtual.
Pentru a evalua imediat subsistemul de stocare, rezultatele benchmark-ului ATTO și CrystalDiskMark sunt prezentate pentru a avea o idee despre punctele nevralgice.
Datele au fost obținute de pe o mașină virtuală:
Rezultatele:
TTFB:
TTFB-ul mediu la IIS este cel mai mic, 0,5ms, comparativ cu 1,4ms la Apache și 4ms la Nginx.
Debitul:
Mai întâi, să ne uităm la cât de bine se scalează fiecare server în funcție de numărul de nuclei.
Pe grafic este prezentat numărul de solicitări ale testerului către serverul web și latența. Este vizibil că NGINX a gestionat 98% din toate solicitările, livrând site-ul în 20ms sau mai puțin. IIS, la fel ca Apache, a gestionat ultimele 5% din toate solicitările în 76ms și respectiv 14ms.
Graficul arată timpul mediu de procesare al unei singure solicitări în timpul testului de stres.
După cum se poate observa din grafice, IIS a fost depășit atât de Apache cât și de Nginx, încetinindu-se semnificativ sub o sarcină mare.
IIS a preferat evident 4 nuclee în fața a opt, arătând întârzieri mai mici la patru, dar, de asemenea, nu a apreciat semnificativ nici un nucleu.
NGINX se scalează perfect pe toate cele 8 nuclee, iar pentru Apache, se pare că un scenariu pe un singur nucleu este cea mai bună alegere.
Scalabilitate:
Nginx:
Acum să analizăm scalabilitatea în funcție de frecvență și numărul de nuclee.
Testele cu o limită de 1% pe 4 și 1 nucleu Nginx nu au trecut, deși a depășit 2000 de cereri, a întrerupt conexiunea cu testatorul.
Apache:
Apache, la fel ca Nginx, a procesat 2500 de cereri, dar s-a predat și a întrerupt conexiunea. Apache nu a trecut testul pe 8, 4 și 1 nucleu cu limita de 1%, dar, pe lângă aceasta, nu a trecut nici testul cu o limită de 5% pe un nucleu, ceea ce este mai rău decât Nginx.
IIS:
IIS a acumulat o coadă uriașă de cereri în timpul testelor, dar a procesat fiecare dintre ele. Se pare că nu are timpi de expirare pentru procesarea cererii din fabrică.
Diagrama ilustrează timpul necesar pentru finalizarea testului. Configurațiile de testare complet absurde au fost eliminate. Din diagramă se poate vedea cât de solicitant este IIS pentru hardware și cât de minunat este NGINX.
Scalabilitate în funcție de disc:
Nginx:
Acum să analizăm scalabilitatea în funcție de frecvență, numărul de nuclee și viteza discului.
De data aceasta, Nginx nu a trecut 4 teste, în loc de două.
Apache:
Apache a eșuat în același număr de teste ca și data trecută.
IIS:
IIS arată un grafic aproape identic, ca și cum nu ar fi existat restricții pe disc. În general, graficele pentru toate serverele nu s-au schimbat semnificativ, ceea ce înseamnă că fiecare dintre ele a stocat statica în memoria RAM și a livrat de acolo. Aici vedem principalul punct slab – serverul web în sine.
Este prea devreme să tragem concluzii pe baza acestui test, nu am testat încă HTTPS, compresia și HTTP/2 cu un certificat activ de la Let’s Encrypt. Vom vorbi despre aceasta în următorul articol.
Sursa: habr.com
