Neste artigo probaremos a enxeñaría inversa, poderíase dicir. Meteremos as nosas mans sucias baixo o capó de cada servidor web, explorándoos de xeitos que ninguén explotaría.
Esta proba é unha medida dun cabalo esférico ao baleiro, nada máis que datos que se obtiveron, e agora non sabemos que facer con el.
Metodoloxía
O sistema operativo para Nginx e Apache é Ubuntu 18.04 LTS, para IIS Windows Server Core 2019. Antes das probas, todos os sistemas operativos recibiron as últimas actualizacións a partir do 04.12.2019 de decembro de XNUMX.
As probas realizáronse exclusivamente a través de HTTP. Cada servidor web executaba a mesma páxina, un modelo Jekyll gratuíto de Codrops. . Cada servidor web tiña a compresión gzip desactivada.
A proba de rendemento realizouse con Httpd-tools cos argumentos:
ab -n 50000 -c 500 http://192.168.76.204:80/Os servidores estaban limitados ao 10, 5 e 1 por cento do núcleo en 8, 4 e un núcleo. O banco de probas era un ordenador con 9900K@5400MHz, o que significa que o servidor que recibe un límite do 10% recibe uns 540MHz por núcleo.
A proba TTFB levouse a cabo cando o servidor se iniciou por primeira vez e mediuse mediante DevTools; despois de recibir o resultado, o servidor apagouse e volveuse ao punto de control anterior para eliminar a aparición de calquera tipo de caché.
O probador e o servidor web estaban no mesmo host e no mesmo interruptor virtual.
Para avaliar inmediatamente o subsistema de disco, os resultados dos benchmarks ATTO e CrystalDIskMark para ter unha idea dos pescozos de botella.
Datos tomados da máquina virtual:
Resultados:
TTFB:
O TTFB medio para IIS é o máis pequeno, 0,5 ms, fronte a 1,4 ms para Apache e 4 ms para Nginx.
Rendemento:
En primeiro lugar, vexamos como se escala cada servidor en función do número de núcleos.
O gráfico mostra o número de chamadas do probador ao servidor web e a latencia. O gráfico mostra que NGINX procesou o 98% de todas as solicitudes, entregando o sitio en 20 ms ou menos. IIS, como Apache, completou o último 5% de todas as chamadas en 76 ms e 14 ms, respectivamente.
O gráfico mostra o tempo medio de procesamento dunha solicitude durante unha proba de esforzo.
Como podes ver nos gráficos, IIS destruíu tanto Apache como Nginx, diminuíndose significativamente baixo unha carga elevada.
IIS prefería claramente 4 núcleos sobre XNUMX, mostrando latencias máis baixas en XNUMX, pero tampouco favorecía moito un núcleo.
NGINX escala ben nos 8 núcleos e, para Apache, o escenario dun só núcleo parece ser a mellor opción.
Escalabilidade:
nginx:
Agora vexamos a escalabilidade en termos de frecuencia e número de núcleos.
Nginx non pasou as probas cun límite do 1% para núcleos 4 e 1; cando superou as 2000 solicitudes, rematou a conexión co probador.
Apache:
Apache, como Nginx, despois de procesar 2500 solicitudes, desistiu e pechou a conexión. Apache fallou a proba en 8, 4 e 1 núcleos cun límite do 1%, pero ademais tamén fallou a proba cun límite do 5% nun núcleo, o que é peor que Nginx
IIS:
Durante as probas, IIS acumulou unha xigantesca cola de solicitudes pero procesou cada unha delas. Ao parecer, fóra da caixa non hai tempo de espera establecido para o procesamento de solicitudes.
O gráfico mostra o tempo que tardou en completar a proba. Desbotáronse as configuracións de proba completamente absurdas. O diagrama mostra o esixente que é IIS cando se trata de hardware e o marabilloso que é NGINX.
Escalabilidade desde o disco:
nginx:
Agora vexamos a escalabilidade en termos de frecuencia e número de núcleos e velocidade do disco.
Esta vez Nginx fallou 4 probas en lugar de dúas.
Apache:
Apache fallou o mesmo número de probas que a última vez.
IIS:
IIS mostra un gráfico case idéntico, coma se non houbese restricións de disco. En xeral, os gráficos de todos os servidores non cambiaron moito, o que significa que cada un deles almacenaba en caché datos estáticos na memoria RAM e serviunos desde alí. Aquí vemos o pescozo de botella principal: o propio servidor web.
É demasiado pronto para sacar conclusións con base nestas probas; aínda non probamos HTTPS, compresión e HTTP/2 cun certificado en directo de Let's Encrypt. Falaremos disto no seguinte artigo.
Fonte: www.habr.com