En este artículo, nos adentraremos en el mundo de la ingeniería inversa, por así decirlo. Echemos un vistazo con nuestras manos sucias debajo del capó de cada uno de los servidores web, explotándolos como nadie lo haría nunca.
Esta prueba es como medir un caballo esférico en un vacío, no son más que datos que hemos recopilado, y ahora no sabemos qué hacer con ellos.
Metodología
El sistema operativo utilizado para Nginx y Apache es Ubuntu 18.04 LTS, y para IIS, Windows Server Core 2019. Todos los sistemas operativos recibieron las últimas actualizaciones hasta el 04.12.2019 antes de las pruebas.
Las pruebas se realizaron exclusivamente a través de HTTP. En cada uno de los servidores web se ejecutaba la misma página, una plantilla gratuita de Jekyll de Codrops. . La compresión gzip estaba desactivada en cada uno de los servidores web.
La prueba de capacidad se realizó con Httpd-tools con los argumentos:
ab -n 50000 -c 500 http://192.168.76.204:80/Se estableció un límite en los servidores del 10, 5 y 1 por ciento del núcleo en 8, 4 y un solo núcleo. El banco de pruebas fue una computadora con 9900K@5400MHz, lo que significa que el servidor al que se le impuso un límite del 10% recibe alrededor de 540MHz por núcleo.
La prueba de TTFB se realizó en la primera carga del servidor y se midió con DevTools, después de obtener el resultado, el servidor se apagó y se restauró al punto de control anterior para evitar cualquier tipo de caché.
El probador y el servidor web estaban en el mismo host y en el mismo switch virtual.
Para evaluar de inmediato el subsistema de disco, se presentan los resultados de los benchmarks ATTO y CrystalDiskMark para tener una idea de los cuellos de botella.
Los datos se tomaron de la máquina virtual:
Resultados:
TTFB:
El TTFB promedio en IIS es el más bajo, 0,5 ms, en comparación con 1,4 ms en Apache y 4 ms en Nginx.
Rendimiento:
Primero, veamos qué tan bien se escala cada uno de los servidores en función de la cantidad de núcleos.
El gráfico muestra el número de solicitudes del probador al servidor web y la latencia. En el gráfico se puede ver que NGINX manejó el 98% de todas las solicitudes, sirviendo el sitio en 20 ms o menos. IIS, al igual que Apache, tardó 76 ms y 14 ms, respectivamente, en manejar el último 5% de todas las solicitudes.
El gráfico muestra el tiempo promedio de procesamiento de una sola solicitud durante la prueba de estrés.
Como se puede observar en los gráficos, IIS fue superado por Apache y Nginx, mostrando un rendimiento significativamente más lento bajo carga alta.
IIS claramente prefirió 4 núcleos sobre ocho, mostrando menores latencias en cuatro, pero tampoco se mostró muy favorable hacia un solo núcleo.
NGINX se escala perfectamente en todos los 8 núcleos, mientras que para Apache, parece que un escenario de un solo núcleo es la mejor opción.
Escalabilidad:
Nginx:
Ahora consideremos la escalabilidad en función de la frecuencia y el número de núcleos.
Las pruebas con un límite del 1% en 4 y 1 núcleo no pasaron para Nginx; al superar los 2000 requests, interrumpió la conexión con el probador.
Apache:
Apache, al igual que Nginx, se rindió después de procesar 2500 solicitudes y rompió la conexión. Apache no pasó la prueba en 8, 4 y 1 núcleo con un límite del 1%, pero además no superó la prueba con un límite del 5% en un solo núcleo, lo cual es peor que Nginx.
IIS:
IIS, durante las pruebas, acumuló una enorme cola de solicitudes, pero procesó cada una de ellas. Al parecer, no tiene configurados por defecto tiempos de espera para el procesamiento de solicitudes.
En el gráfico se muestra el tiempo que tomó finalizar la prueba. Se descartaron configuraciones de prueba completamente absurdas. Del gráfico se puede ver la cantidad de recursos que requiere IIS y lo impresionante que es NGINX.
Escalabilidad del disco:
Nginx:
Ahora consideremos la escalabilidad en función de la frecuencia, la cantidad de núcleos y la velocidad del disco.
Esta vez Nginx no pasó 4 pruebas, en lugar de dos.
Apache:
Apache fracasó en la misma cantidad de pruebas que la vez anterior.
IIS:
IIS muestra un gráfico casi idéntico, como si no hubiera limitaciones en el disco. En general, los gráficos de todos los servidores no han cambiado mucho, lo que significa que cada uno de ellos está almacenando en caché los estáticos en la memoria RAM y los entrega desde ahí. Aquí vemos el principal cuello de botella: el propio servidor web.
Es prematuro hacer conclusiones basadas en estas pruebas; aún no hemos probado HTTPS, compresión y HTTP/2 con un certificado activo de Let’s Encrypt. Sobre esto hablaremos en el siguiente artículo.
Fuente: habr.com
