Sobre la metodología hablamos en el artículo, en este probamos HTTPS, pero en escenarios más realistas. Para la prueba, se obtuvo un certificado Let’s Encrypt y se activó la compresión Brotli al 11%.
Esta vez intentaremos reproducir un escenario de despliegue de servidor en un VDS o como una máquina virtual en un host con un procesador estándar. Para ello, se estableció un límite en:
- 25% — Lo que equivale a una frecuencia de ~ 1350MHz
- 35% -1890MHz
- 41% — 2214MHz
- 65% — 3510MHz
El número de conexiones simultáneas se redujo de 500 a 1, 3, 5, 7 y 9,
Resultados:
Retardos:
TTFB se separó como prueba independiente porque HTTPD Tools crea como si fuera un nuevo usuario para cada solicitud individual. Esta prueba todavía está bastante alejada de la realidad, porque un usuario de todas formas hará clic en un par de páginas, y en la realidad, el TTFP jugará el papel principal.
La primera, en realidad la primera solicitud después del primer inicio de la máquina virtual IIS se completa en un promedio de 120 ms.
Todas las solicitudes posteriores muestran un TTFP de 1.5 ms. Apache y Nginx están por detrás en esto. Personalmente, el autor considera que esta prueba es la más indicativa y elegiría al ganador solo por ella.
El resultado no es sorprendente, ya que IIS almacena en caché el contenido estático ya comprimido y no lo recomprime cada vez que se accede a él.
Tiempo gastado por un cliente
Para evaluar el rendimiento, una prueba con 1 conexión simultánea es suficiente.
Por ejemplo, IIS completó la prueba de 5000 usuarios en 40 segundos, lo que equivale a 123 solicitudes por segundo.
En los gráficos a continuación se muestra el tiempo hasta la transmisión completa del contenido del sitio. Esta es la proporción de solicitudes completadas en un tiempo determinado. En nuestro caso, el 80% de todas las solicitudes fueron procesadas en 8ms en IIS y en 4.5ms en Apache y Nginx, mientras que el intervalo hasta 8 milisegundos se completaron el 98% de todas las solicitudes en Apache y Nginx.
El tiempo que tomó procesar 5000 solicitudes:
El tiempo que tomó procesar 5000 solicitudes:
Si tiene una máquina virtual con un CPU de 3.5GHz y 8 núcleos, elija lo que desee. Todos los servidores web son muy similares en esta prueba. Hablaremos de qué servidor web elegir para cada host más adelante.
Cuando se trata de una situación un poco más realista, todos los servidores web están codo a codo.
Rendimiento:
Gráfico de retardos según el número de conexiones simultáneas. Más uniforme y más bajo – mejor. Se eliminaron el 2% final de los gráficos porque los harían ilegibles.
Ahora consideremos la opción donde el servidor se aloja en un hosting virtual. Tomemos 4 núcleos a 2.2 GHz y un núcleo a 1.8 GHz.
Cómo se escalan
Si alguna vez has visto cómo lucen las curvas de salida de triodos y pentodos electrónicos, estos gráficos te serán familiares. Precisamente eso intentamos capturar: la saturación. El límite en el que, sin importar cuántos núcleos añadas, el aumento en el rendimiento no será perceptible.
Anteriormente, el desafío consistía en procesar el 98% de las solicitudes con la menor latencia posible en todas ellas, manteniendo la curva lo más uniforme posible. Ahora, mediante la construcción de otra curva, encontraremos el punto de trabajo óptimo para cada uno de los servidores.
Para esto, tomaremos la métrica de Solicitudes por segundo (RPR). En el eje horizontal, la frecuencia; en el vertical, la cantidad de solicitudes procesadas por segundo; las líneas representan la cantidad de núcleos.
Se muestra la correlación de cuán bien Nginx maneja las solicitudes una tras otra. 8 núcleos en este tipo de pruebas demuestran ser más efectivos.
En este gráfico se puede ver claramente cuán mejor (no mucho) trabaja Nginx en un solo núcleo. Si utilizas Nginx, deberías considerar reducir la cantidad de núcleos a uno, si solo alojas contenido estático.
IIS, aunque tiene el TTFB más bajo según DevTools en Chrome, logra ser superado tanto por Nginx como por Apache en una competencia seria de pruebas de estrés de Apache Foundation.
Toda la curvatura de los gráficos se reproduce de manera precisa.
Una especie de conclusión:
Sí, Apache efectivamente funciona peor con 1 y 8 núcleos, mientras que con 4 funciona un poco mejor.
Sí, Nginx maneja mejor las solicitudes una tras otra en 8 núcleos, y en 1 y 4 núcleos funciona peor cuando hay muchas conexiones.
Sí, IIS prefiere 4 núcleos para cargas multihilo y prefiere 8 núcleos para cargas un hilo. Al final, IIS resultó ser un poco más rápido que todos en 8 núcleos bajo alta carga, aunque todos los servidores operaban en paralelo.
Esto no es un error de medición, la variación no supera +-1 ms en latencias y no más de +-2-3 solicitudes por segundo para RPR.
Los resultados, donde 8 núcleos muestran un rendimiento inferior, no son sorprendentes; muchos núcleos y SMT/Hyperthreading degradan significativamente el rendimiento si tenemos plazos dentro de los cuales debemos finalizar todo el pipeline.
Fuente: habr.com
