Neste artigo, probaremos a enxeñaría inversa, por así dicilo. Meteremos mans nas entrañas de cada servidor web, explotándoos de xeitos que ninguén máis aproveitaría xamais.
Esta proba é unha medición dun cabalo esférico no baleiro, nada máis que os datos que se obtiveron, e agora non sabemos que facer con eles.
Metodoloxía
O sistema operativo para Nginx e Apache é Ubuntu 18.04 LTS, para IIS Windows Server Core 2019. Todos os sistemas operativos recibiron as últimas actualizacións o 4 de decembro de 2019, antes das probas.
As probas realizáronse exclusivamente a través de HTTP. Cada servidor web executou a mesma páxina, un modelo de Jekyll gratuíto de Codrops. A compresión Gzip foi desactivada en todos os servidores web.
A proba de rendemento realizouse con ferramentas Httpd cos seguintes 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 1 núcleo. O banco de probas foi un computador con 9900K a 5400 MHz, o que significa que un servidor cun límite do 10 % recibe aproximadamente 540 MHz por núcleo.
A proba TTFB realizouse durante o primeiro arranque do servidor e mediuse con DevTools. Despois de recibir os resultados, o servidor apagouse e volveuse ao punto de control anterior para eliminar calquera caché.
O probador e o servidor web estaban situados no mesmo host e no mesmo conmutador virtual.
Para avaliar inmediatamente o subsistema de disco, utilízanse os resultados das probas de referencia de ATTO e CrystalDIskMark para ter unha idea dos atascos.
Datos tomados da máquina virtual:
Resultados:
TTFB:
IIS ten o TTFB medio máis baixo, 0,5 ms, en comparación con 1,4 ms de Apache e 4 ms de Nginx.
Rendemento:
Primeiro, vexamos o ben que se escala cada servidor en termos de número de núcleos.
O gráfico mostra o número de solicitudes que o tester fixo ao servidor web e a latencia. Mostra que NGINX xestionou o 98 % de todas as solicitudes, entregando o sitio en 20 ms ou menos. IIS e Apache xestionaron o último 5 % de todas as solicitudes en 76 ms e 14 ms, respectivamente.
O gráfico mostra o tempo medio de procesamento dunha solicitude durante unha proba de estrés.
Como se pode ver nos gráficos, IIS superou tanto a Apache como a Nginx, ralentizándose significativamente con cargas elevadas.
IIS claramente preferiu 4 núcleos sobre 8, mostrando latencias máis baixas en 4, pero tampouco favoreceu moito 1 núcleo.
NGINX escala ben nos 8 núcleos, mentres que para Apache, o escenario dun só núcleo parece ser a mellor opción.
Escalabilidade:
nginx:
Agora vexamos a escalabilidade por frecuencia e número de núcleos.
Nginx fallou as probas cun límite do 1 % en 4 e 1 núcleo; cando superou as 2000 solicitudes, finalizou a conexión co tester.
Apache:
Apache, como Nginx, rendeuse e finalizou a conexión despois de procesar 2500 solicitudes. Apache fallou nas probas en 8, 4 e 1 núcleo cun límite do 1 %, pero tamén fallou na proba cun límite do 5 % nun só núcleo, o que é peor que Nginx.
IIS:
Durante as probas, IIS acumulou unha cola xigantesca de solicitudes, pero procesounas todas. Ao parecer, non ten ningún tempo de espera de procesamento de solicitudes configurado de fábrica.
O diagrama mostra o tempo que levou completar a proba. Descartáronse as configuracións de proba máis absurdas. O diagrama demostra o esixente que é IIS en canto ao hardware e o marabilloso que é NGINX.
Escalabilidade do disco:
nginx:
Agora vexamos a escalabilidade en termos de frecuencia, 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 almacenou ficheiros estáticos na caché da RAM e os serviu desde alí. Aquí vemos o principal colo de botella: o propio servidor web.
É demasiado cedo para sacar conclusións destas probas; aínda non probamos HTTPS, compresión e HTTP/2 cun certificado Let's Encrypt activo. Abordaremos iso no seguinte artigo.
Fonte: www.habr.com
