En aquest article provarem l'enginyeria inversa, es podria dir. Ens posarem les mans brutes sota el capó de cada servidor web, explotant-los d'una manera que ningú no explotaria mai.
Aquesta prova és una mesura d'un cavall esfèric al buit, res més que dades que es van obtenir, i ara no sabem què fer-hi.
Metodologia
El sistema operatiu per a Nginx i Apache és Ubuntu 18.04 LTS, per a IIS Windows Server Core 2019. Abans de les proves, tots els sistemes operatius van rebre les últimes actualitzacions a partir del 04.12.2019 de desembre de XNUMX.
Les proves es van realitzar exclusivament a través d'HTTP. Cada servidor web tenia la mateixa pàgina, una plantilla Jekyll gratuïta de Codrops. . Cada servidor web tenia la compressió gzip desactivada.
La prova de rendiment es va fer amb Httpd-tools amb els arguments:
ab -n 50000 -c 500 http://192.168.76.204:80/Els servidors estaven limitats al 10, 5 i 1 per cent del nucli en 8, 4 i un nucli. El banc de proves era un ordinador amb 9900K@5400MHz, el que significa que el servidor que rep un límit del 10% rep uns 540MHz per nucli.
La prova TTFB es va dur a terme quan el servidor es va iniciar per primera vegada i es va mesurar amb DevTools; després de rebre el resultat, el servidor es va apagar i es va tornar al punt de control anterior per eliminar l'aparició de qualsevol tipus de memòria cau.
El provador i el servidor web estaven al mateix host i al mateix commutador virtual.
Per avaluar immediatament el subsistema de disc, els resultats dels punts de referència ATTO i CrystalDIskMark per tenir una idea dels colls d'ampolla.
Dades extretes de la màquina virtual:
Resultats:
TTFB:
El TTFB mitjà per a IIS és el més petit, 0,5 ms, enfront dels 1,4 ms per a Apache i 4 ms per a Nginx.
Rendiment:
Primer, mirem com s'escala cada servidor en funció del nombre de nuclis.
El gràfic mostra el nombre de trucades del provador al servidor web i la latència. El gràfic mostra que NGINX va processar el 98% de totes les sol·licituds, lliurant el lloc en 20 ms o menys. IIS, com Apache, va completar l'últim 5% de totes les trucades en 76 ms i 14 ms, respectivament.
El gràfic mostra el temps mitjà de processament d'una sol·licitud durant una prova d'esforç.
Com podeu veure als gràfics, IIS va fer volar tant Apache com Nginx, alentint-se significativament amb una càrrega elevada.
IIS preferia clarament 4 nuclis sobre XNUMX, mostrant latències més baixes en XNUMX, però tampoc no afavoria gaire un nucli.
NGINX escala bé als 8 nuclis, i per a Apache, l'escenari d'un sol nucli sembla ser la millor opció.
Escalabilitat:
Nginx:
Ara mirem l'escalabilitat en termes de freqüència i nombre de nuclis.
Nginx no va passar proves amb un límit de l'1% per a 4 i 1 nuclis; quan va superar les 2000 sol·licituds, va finalitzar la connexió amb el provador.
Apache:
Apache, com Nginx, després d'haver processat 2500 sol·licituds, va renunciar i va tancar la connexió. Apache va fallar la prova en 8, 4 i 1 nuclis amb un límit de l'1%, però a més d'això, també va fallar la prova amb un límit del 5% en un nucli, que és pitjor que Nginx
IIS:
Durant les proves, IIS va acumular una cua gegantina de peticions però va processar cadascuna d'elles. Aparentment, fora de la caixa no hi ha temps d'espera establerts per al processament de sol·licituds.
El gràfic mostra el temps que va trigar a completar la prova. Es van descartar configuracions de prova completament absurdes. El diagrama mostra l'exigència que és IIS quan es tracta de maquinari i el meravellós que és NGINX.
Escalabilitat des del disc:
Nginx:
Vegem ara l'escalabilitat en termes de freqüència i nombre de nuclis i velocitat de disc.
Aquesta vegada Nginx va fallar 4 proves en lloc de dues.
Apache:
Apache va fallar el mateix nombre de proves que la darrera vegada.
IIS:
IIS mostra un gràfic gairebé idèntic, com si no hi hagués restriccions de disc. En general, els gràfics de tots els servidors no van canviar gaire, la qual cosa significa que cadascun d'ells guardava dades estàtiques a la memòria cau a la memòria RAM i les servia des d'allà. Aquí veiem el coll d'ampolla principal: el propi servidor web.
És massa aviat per treure conclusions basant-se en aquestes proves; encara no hem provat HTTPS, compressió i HTTP/2 amb un certificat en directe de Let's Encrypt. En parlarem en el proper article.
Font: www.habr.com