La batalla de los servidores web. Parte 1 - HTTP divorciado de la realidad:

En este artículo intentaremos nosotros mismos en ingeniería inversa, se podría decir. Con las manos sucias, miramos bajo el capó de cada uno de los servidores web, explotándolos como nadie lo habría explotado jamás.

Esta prueba es una medida de un caballo esférico en el vacío, nada más que los datos que se recibieron, y ahora no sabemos qué hacer con ellos.


Metodología


El sistema operativo para Nginx y Apache es Ubuntu 18.04 LTS, para IIS Windows Server Core 2019. Todos los sistemas operativos antes de las pruebas recibieron las últimas actualizaciones el 4 de diciembre de 2019.

Las pruebas se realizaron exclusivamente a través de HTTP. Cada servidor web tenía la misma página, una plantilla gratuita para Jekyll de Codrops. Enlace En cada uno de los servidores web, la compresión gzip estaba desactivada.

La prueba de ancho de banda se realizó con herramientas Httpd con argumentos:

ab -n 50000 -c 500 http://192.168.76.204:80/ 

Los servidores se establecieron en un límite de 10, 5 y 1 por ciento del núcleo en 8, 4 y un núcleo. Como banco de pruebas, había una computadora con 9900K a 5400 MHz, lo que significa que el servidor, que recibió un límite del 10%, recibe aproximadamente 540 MHz por núcleo.

La prueba TTFB se llevó a cabo en el primer arranque del servidor y se midió usando DevTools, después de recibir el resultado, el servidor se apagó y volvió al punto de control anterior para excluir 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 comprender los cuellos de botella.

Datos tomados de la máquina virtual:





Resultados:


TTFB:


El TTFB promedio para IIS es el mínimo, 0.5ms, versus 1.4ms para Apache y 4ms para Nginx.

Rendimiento:

Primero, considere qué tan bien escala cada servidor en términos de la cantidad de núcleos.


El gráfico muestra el número de llamadas del probador al servidor web y la latencia. El gráfico muestra que NGINX logró el 98% de todos los éxitos, lo que le da al sitio 20 ms o menos. IIS y Apache duran el 5% de todas las llamadas trabajadas durante 76ms y 14ms, respectivamente.




El gráfico muestra el tiempo de procesamiento promedio para una solicitud durante una prueba de esfuerzo.

Como puede ver en los gráficos, IIS sopló tanto Apache como Nginx, desacelerando significativamente bajo una carga alta.

IIS claramente prefería 4 núcleos sobre ocho, mostrando menos demoras en cuatro, pero tampoco respaldaba fuertemente un núcleo.

NGINX escala perfectamente a los 8 núcleos, y para Apache, parece que un script de un solo núcleo parece ser la mejor opción.

Escalabilidad:


Nginx:

Ahora considere la escalabilidad en frecuencia y número de núcleos.


Las pruebas con un límite del 1% en 4 y 1 núcleos Nginx no pasaron, dejando 2000 solicitudes, se desconectó del probador.

Apache


Después de procesar 2500 solicitudes, Apache como Nginx se rindió y desconectó. Apache no pasó la prueba en 8, 4 y 1 núcleos con un límite del 1%, pero además, la prueba en el límite del 5% en un núcleo no pasó, lo cual es peor que Nginx

IIS:


IIS durante las pruebas reunió una cola gigante de solicitudes pero procesó cada una de ellas. Aparentemente, los tiempos de espera listos para usar para procesar la solicitud no están configurados.


El diagrama muestra el tiempo necesario para completar la prueba. Absurdamente absurdas configuraciones de prueba fueron descartadas. El diagrama muestra cómo IIS exige hardware y cuán hermoso es NGINX.

Escalabilidad de disco:


Nginx:

Ahora considere la escalabilidad en frecuencia y número de núcleos y velocidad de disco.


Esta vez, Nginx falló 4 pruebas, en lugar de dos.

Apache


Apache falló el mismo número de pruebas, como 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 han cambiado mucho, lo que significa que cada uno de ellos almacenó en caché las estadísticas en RAM y las proporcionó desde allí. Aquí vemos el cuello de botella principal: el servidor web en sí.

Es demasiado pronto para sacar conclusiones basadas en estas pruebas; todavía no hemos probado HTTPS, compresión y HTTP / 2 con un certificado en vivo de Let's Encrypt. Hablaremos de esto en el próximo artículo.

Ofrecemos una tarifa UltraLite Windows VDS actualizada por 99 rublos con Windows Server 2019 Core instalado.

Source: https://habr.com/ru/post/478854/


All Articles