Hablamos sobre la técnica en la
primera parte del artículo, en esto probamos HTTPS, pero en escenarios más realistas. Para las pruebas, se recibió el certificado Let's Encrypt, se habilitó la compresión Brotli por 11.
Esta vez intentaremos reproducir el escenario de implementación del servidor en VDS o como una máquina virtual en un host con un procesador típico. Para hacer esto, establezca el límite en:
- 25% - Que en términos de frecuencia ~ 1350MHz
- 35% -1890MHz
- 41% - 2214MHz
- 65% - 3510MHz
El número de conexiones únicas disminuyó de 500 a 1, 3, 5, 7 y 9,
Resultados:
Retrasos:
TTFB se hizo especialmente como una prueba separada, porque HTTPD Tools crea un nuevo usuario para cada solicitud individual. Esta prueba todavía está bastante divorciada de la realidad, porque el usuario hace clic en un par de páginas de todos modos, y en realidad TTFP desempeñará el papel principal.
La primera, generalmente la primera solicitud, después del primer inicio de la máquina virtual, IIS procesa un promedio de 120 ms.
Todas las solicitudes posteriores muestran un TTFP de 1,5 ms. Apache y Nginx están rezagados. Personalmente, el autor considera que esta prueba es la más reveladora y elegiría un ganador solo en ella.
El resultado no es sorprendente, ya que IIS almacena en caché contenido estático comprimido y no lo pellizca cada vez que se accede a él.
Tiempo dedicado a un cliente
Para evaluar el rendimiento, una prueba con 1 conexión única es suficiente.
Por ejemplo, IIS completó las pruebas con una longitud de 5,000 usuarios en 40 segundos, que son 123 solicitudes por segundo.
Los gráficos a continuación muestran el tiempo hasta la transferencia completa del contenido del sitio. Este es el porcentaje de solicitudes completadas en un momento específico. En nuestro caso, el 80% de todas las solicitudes se procesaron en 8 ms en IIS y en 4,5 ms en Apache y Nginx, y el 98% de todas las solicitudes en Apache y Nginx se ejecutaron dentro de un intervalo de 8 milisegundos.
El tiempo necesario para procesar 5000 solicitudes:
El tiempo necesario para procesar 5000 solicitudes:
Si tiene una máquina virtual con una CPU de 3.5 GHz y 8 núcleos, elija lo que desee. Todos los servidores web son muy similares en esta prueba. A continuación, hablaremos sobre qué servidor web elegir para cada host.
Cuando se trata de una situación un poco más real, todos los servidores web se enfrentan cara a cara.
Rendimiento:
Programa de retrasos en el número de conexiones simultáneas. Más suave y más bajo es mejor. El último 2% se eliminó de los gráficos porque los haría ilegibles.
Ahora considere la opción donde el servidor está alojado en un alojamiento compartido. Tome 4 núcleos a 2.2 GHz y un núcleo a 1.8 GHz.
Cómo escalar
Si alguna vez ha visto cómo se ven las características I - V de los triodos, pentodos, etc. de electrovacío, estos gráficos le resultarán familiares. Eso es lo que estamos tratando de atrapar: la saciedad. El límite es, cuando no arroja cuántos núcleos, el crecimiento de la productividad no se notará.
Anteriormente, el desafío completo era procesar el 98% de las solicitudes con el menor retraso en todas las solicitudes, para mantener la curva lo más uniforme posible. Ahora, utilizando la construcción de otra curva, encontramos el punto de funcionamiento óptimo para cada uno de los servidores.
Para hacer esto, tome la métrica Solicitudes por segundo (RPR). Frecuencia horizontal, vertical: el número de solicitudes procesadas por segundo, líneas: el número de núcleos.
Se muestra una correlación de qué tan bien Nginx maneja las solicitudes una por una. 8 núcleos en tales pruebas se muestran mejor.
Este gráfico muestra claramente cuánto mejor (no mucho) Nginx se ejecuta en un solo núcleo. Si tiene Nginx, debería considerar reducir el número de núcleos a uno si solo aloja estadísticas estáticas.
IIS, aunque tiene el TTFB más bajo según DevTools en Chrome, logra perder tanto Nginx como Apache en una lucha seria contra la prueba de estrés de la Fundación Apache.
Toda la curvatura de los gráficos se reproduce en tren.
Una especie de conclusión:
Sí, Apache funciona peor en los núcleos 1 y 8, y en 4 funciona un poco mejor.
Sí, Nginx en 8 núcleos maneja mejores solicitudes una tras otra, en 1 y 4 núcleos, y funciona peor cuando hay muchas conexiones.
Sí, IIS prefiere 4 núcleos para carga multiproceso y prefiere 8 núcleos para subproceso único. Al final, IIS fue un poco más rápido que todos en 8 núcleos bajo alta carga, aunque todos los servidores se enjuagaron.
Esto no es un error de medición, el error aquí no es más de + -1ms. en retrasos y no más de + - 2-3 solicitudes por segundo para RPR.
Los resultados, cuando 8 núcleos son peores, no son nada sorprendentes, muchos núcleos y SMT / Hyperthreading degradan severamente el rendimiento si tenemos el marco de tiempo para el que debemos completar toda la tubería.
Ofrecemos una tarifa UltraLite
Windows VDS actualizada por 99 rublos con Windows Server 2019 Core instalado.
