En este artículo probaremos la ingeniería inversa, se podría decir. Nos meteremos las manos sucias bajo el capó de cada servidor web, explotándolos de maneras que nadie jamás explotaría.
Esta prueba es una medición de un caballo esférico en el vacío, no es más que un dato que se obtuvo, y ahora no sabemos qué hacer con él.
Metodología
El sistema operativo para Nginx y Apache es Ubuntu 18.04 LTS, para IIS Windows Server Core 2019. Antes de las pruebas, todos los sistemas operativos recibieron las últimas actualizaciones a partir del 04.12.2019 de diciembre de XNUMX.
Las pruebas se realizaron exclusivamente a través de HTTP. Cada servidor web ejecutaba la misma página, una plantilla Jekyll gratuita de Codrops. . Cada servidor web tenía la compresión gzip deshabilitada.
La prueba de rendimiento se realizó con Httpd-tools con los argumentos:
ab -n 50000 -c 500 http://192.168.76.204:80/Los servidores estaban limitados al 10, 5 y 1 por ciento del núcleo en 8, 4 y un núcleo. El banco de pruebas fue una computadora con 9900K@5400MHz, lo que significa que el servidor que recibe un límite del 10% recibe alrededor de 540MHz por núcleo.
La prueba TTFB se llevó a cabo cuando el servidor se inició por primera vez y se midió usando DevTools; después de recibir el resultado, el servidor se apagó y se retrocedió al punto de control anterior para eliminar la aparición de cualquier tipo de caché.
El probador y el servidor web estaban en el mismo host y en el mismo conmutador virtual.
Para evaluar inmediatamente el subsistema de disco, los resultados de los puntos de referencia ATTO y CrystalDIskMark para tener una idea de los cuellos de botella.
Datos tomados de la máquina virtual:
resultados:
TTFB:
El TTFB promedio para IIS es el más pequeño, 0,5 ms, frente a 1,4 ms para Apache y 4 ms para Nginx.
rendimiento:
Primero, veamos qué tan bien se escala cada servidor según la cantidad de núcleos.
El gráfico muestra la cantidad de llamadas del probador al servidor web y la latencia. El gráfico muestra que NGINX procesó el 98% de todas las solicitudes y entregó el sitio en 20 ms o menos. IIS, al igual que Apache, completó el último 5% de todas las llamadas en 76 ms y 14 ms, respectivamente.
El gráfico muestra el tiempo promedio de procesamiento de una solicitud durante una prueba de estrés.
Como puede ver en los gráficos, IIS superó tanto a Apache como a Nginx, ralentizándose significativamente bajo cargas elevadas.
IIS claramente prefirió 4 núcleos a XNUMX, mostrando latencias más bajas en XNUMX, pero tampoco favoreció mucho un núcleo.
NGINX se adapta bien a los 8 núcleos y, para Apache, el escenario de un solo núcleo parece ser la mejor opción.
Escalabilidad:
Nginx:
Ahora veamos la escalabilidad en términos de frecuencia y cantidad de núcleos.
Nginx no pasó las pruebas con un límite del 1% para 4 y 1 núcleos; cuando superó las 2000 solicitudes, cortó la conexión con el probador.
Apache:
Apache, al igual que Nginx, después de procesar 2500 solicitudes, se rindió y cerró la conexión. Apache no pasó la prueba en 8, 4 y 1 núcleos con un límite del 1%, pero además también falló la prueba con un límite del 5% en un núcleo, lo cual es peor que Nginx.
IIS:
Durante las pruebas, IIS acumuló una cola gigantesca de solicitudes pero procesó cada una de ellas. Aparentemente, no hay tiempos de espera establecidos para el procesamiento de solicitudes.
El gráfico muestra el tiempo que tomó completar la prueba. Se descartaron configuraciones de prueba completamente absurdas. El diagrama muestra lo exigente que es IIS cuando se trata de hardware y lo maravilloso que es NGINX.
Escalabilidad desde disco:
Nginx:
Ahora veamos la escalabilidad en términos de frecuencia, número de núcleos y velocidad del disco.
Esta vez Nginx falló 4 pruebas en lugar de dos.
Apache:
Apache falló la misma cantidad de pruebas que la última vez.
IIS:
IIS muestra un gráfico casi idéntico, como si no hubiera restricciones de disco. En general, los gráficos de todos los servidores no cambiaron mucho, lo que significa que cada uno de ellos almacenó en caché los datos estáticos en la RAM y los sirvió desde allí. Aquí vemos el principal cuello de botella: el propio servidor web.
Es demasiado pronto para sacar conclusiones basadas en estas pruebas; todavía no hemos probado HTTPS, compresión y HTTP/2 con un certificado activo de Let's Encrypt. Hablaremos de esto en el próximo artículo.
Fuente: habr.com