În acest articol ne vom încerca mâna la inginerie inversă, s-ar putea spune. Ne vom pune mâinile murdare sub capota fiecărui server web, exploatându-le în moduri pe care nimeni nu le-ar exploata vreodată.
Acest test este o măsurătoare a unui cal sferic în vid, nimic mai mult decât date care au fost obținute, iar acum nu știm ce să facem cu el.
tehnică
Sistemul de operare pentru Nginx și Apache este Ubuntu 18.04 LTS, pentru IIS Windows Server Core 2019. Toate sistemele de operare au primit cele mai recente actualizări începând cu 4 decembrie 2019, înainte de testare.
Testele au fost efectuate exclusiv prin HTTP. Fiecare server web rula aceeași pagină, un șablon Jekyll gratuit de la Codrops. . Fiecare server web avea compresia gzip dezactivată.
Testul de debit a fost făcut 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 nucleu pe 8, 4 și un nucleu. Bancul de testare a fost un computer cu 9900K@5400MHz, ceea ce înseamnă că serverul care primește o limită de 10% primește aproximativ 540MHz per nucleu.
Testul TTFB a fost efectuat când serverul a pornit pentru prima dată și a fost măsurat folosind DevTools, după ce a primit rezultatul, serverul a fost oprit și revenit la punctul de control anterior pentru a elimina orice fel de cache.
Testerul și serverul web se aflau pe aceeași gazdă și pe același switch virtual.
Pentru a evalua imediat subsistemul de disc, rezultatele benchmark-urilor ATTO și CrystalDIskMark pentru a avea o idee despre blocajele.
Date preluate de pe mașina virtuală:
Rezultate:
TTFB:
TTFB mediu pentru IIS este cel mai mic, 0,5 ms, față de 1,4 ms pentru Apache și 4 ms pentru Nginx.
Randament:
În primul rând, să ne uităm la cât de bine se scalează fiecare server în funcție de numărul de nuclee.
Graficul arată numărul de apeluri de la tester către serverul web și latența. Graficul arată că NGINX a procesat 98% din toate solicitările, livrând site-ul în 20 ms sau mai puțin. IIS, la fel ca Apache, a finalizat ultimele 5% din toate apelurile în 76ms, respectiv 14ms.
Graficul arată timpul mediu de procesare pentru o cerere în timpul unui test de stres.
După cum puteți vedea din grafice, IIS a distrus atât Apache, cât și Nginx, încetinind semnificativ la sarcină mare.
IIS a preferat în mod clar 4 nuclee față de XNUMX, arătând latențe mai mici pe XNUMX, dar nici nu a favorizat puternic un nucleu.
NGINX se scalează bine pe toate cele 8 nuclee, iar pentru Apache, scenariul cu un singur nucleu pare a fi cea mai bună alegere.
Scalabilitate:
Nginx:
Acum să ne uităm la scalabilitate în ceea ce privește frecvența și numărul de nuclee.
Nginx nu a trecut teste cu o limită de 1% pentru 4 și 1 nuclee când a depășit 2000 de solicitări, a încheiat conexiunea cu testerul;
Apache:
Apache, ca și Nginx, după ce a procesat 2500 de solicitări, a renunțat și a închis conexiunea. Apache a picat testul pe 8, 4 și 1 nuclee cu o limită de 1%, dar în plus a picat și testul cu o limită de 5% pe un nucleu, ceea ce este mai rău decât Nginx
IIS:
În timpul testelor, IIS a acumulat o coadă gigantică de solicitări, dar a procesat fiecare dintre ele. Aparent, nu există timeout-uri setate pentru procesarea cererilor.
Tabelul arată timpul necesar pentru finalizarea testului. Configurațiile de testare complet absurde au fost eliminate. Diagrama arată cât de solicitant este IIS când vine vorba de hardware și cât de minunat este NGINX.
Scalabilitate de pe disc:
Nginx:
Acum să ne uităm la scalabilitate în ceea ce privește frecvența și numărul de nuclee și viteza discului.
De data aceasta, Nginx a eșuat la 4 teste în loc de două.
Apache:
Apache a eșuat la același număr de teste ca data trecută.
IIS:
IIS arată un grafic aproape identic, de parcă nu ar exista restricții de disc. În general, grafica tuturor serverelor nu s-a schimbat prea mult, ceea ce înseamnă că fiecare dintre ele a stocat în cache date statice în RAM și le-a servit de acolo. Aici vedem blocajul principal - serverul web în sine.
Este prea devreme pentru a trage concluzii pe baza acestor teste, nu am testat încă HTTPS, compresia și HTTP/2 cu un certificat live de la Let's Encrypt. Vom vorbi despre asta în următorul articol.
Sursa: www.habr.com
