Hablamos de la metodología en artículo, en este probamos HTTPS, pero en escenarios más realistas. Para las pruebas, obtuvimos un certificado Let's Encrypt y habilitamos la compresión Brotli a 11.
En esta ocasión intentaremos reproducir el escenario de implementar un servidor en un VDS o como una máquina virtual en un host con un procesador estándar. Para ello se fijó un límite de:
- 25% - Lo que equivale a una frecuencia de ~1350 MHz
- 35% -1890MHz
- 41% - 2214MHz
- 65% - 3510MHz
El número de conexiones únicas se ha reducido de 500 a 1, 3, 5, 7 y 9.
resultados:
Retrasos:
TTFB se incluyó específicamente como una prueba separada, porque HTTPD Tools crea un nuevo usuario para cada solicitud individual. Esta prueba todavía está bastante alejada de la realidad, porque el usuario seguirá haciendo clic en un par de páginas 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, tarda una media de 120 ms.
Todas las solicitudes posteriores muestran un TTFP de 1.5 ms. Apache y Nginx se están quedando atrás en este sentido. Personalmente, el autor considera que esta prueba es la más reveladora y elegiría al ganador únicamente basándose en ella.
El resultado no es sorprendente ya que IIS almacena en caché el contenido estático ya comprimido y no lo comprime cada vez que se accede a él.
Tiempo empleado por cliente
Para evaluar el rendimiento es suficiente una prueba con 1 sola conexión.
Por ejemplo, IIS completó una prueba de 5000 usuarios en 40 segundos, lo que equivale a 123 solicitudes por segundo.
Los gráficos a continuación muestran el tiempo hasta que el contenido del sitio se transfiere por completo. Esta es la proporción de solicitudes completadas en un tiempo determinado. 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 8% de todas las solicitudes en Apache y Nginx se completaron en un intervalo de hasta 98 milisegundos.
Tiempo durante el cual se procesaron 5000 solicitudes:
Tiempo durante el cual se procesaron 5000 solicitudes:
Si tienes una máquina virtual con una CPU de 3.5 GHz y 8 núcleos, elige lo que quieras. Todos los servidores web son muy similares en esta prueba. Hablaremos sobre qué servidor web elegir para cada host a continuación.
Cuando se trata de una situación un poco más realista, todos los servidores web van cara a cara.
rendimiento:
Gráfico de retrasos versus el número de conexiones simultáneas. Cuanto más suave y más bajo, mejor. El último 2% se eliminó de los gráficos porque los haría ilegibles.
Ahora consideremos la opción donde el servidor está alojado en un alojamiento virtual. Tomemos 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 son las características corriente-voltaje de los triodos, pentodos, etc. del vacío, estos gráficos le resultarán familiares. Esto es lo que estamos tratando de detectar: la saturación. El límite es cuando no importa cuántos núcleos arrojes, el aumento de rendimiento no será notable.
Anteriormente, todo el desafío consistía en procesar el 98 % de las solicitudes con la latencia más baja para todas las solicitudes, manteniendo la curva lo más plana posible. Ahora, construyendo otra curva, encontraremos el punto de funcionamiento óptimo para cada uno de los servidores.
Para hacer esto, tomemos el indicador de Solicitudes por segundo (RPR). Horizontal es la frecuencia, vertical es la cantidad de solicitudes procesadas por segundo, las líneas son la cantidad de núcleos.
Muestra una correlación de qué tan bien Nginx procesa las solicitudes una tras otra. 8 núcleos funcionan mejor en esta prueba.
Este gráfico muestra claramente cuánto mejor (no mucho) funciona Nginx en un solo núcleo. Si tiene Nginx, debería considerar reducir la cantidad de núcleos a uno si solo aloja núcleos estáticos.
IIS, aunque tiene el TTFB más bajo según DevTools en Chrome, logra perder frente a Nginx y Apache en una pelea seria con la prueba de estrés de la Fundación Apache.
Toda la curvatura de los gráficos se reproduce férreamente.
Algún tipo de conclusión:
Sí, Apache funciona peor en 1 y 8 núcleos, pero funciona un poco mejor en 4.
Sí, Nginx en 8 núcleos procesa las solicitudes mejor una tras otra, en 1 y 4 núcleos, y funciona peor cuando hay muchas conexiones.
Sí, IIS prefiere 4 núcleos para cargas de trabajo de subprocesos múltiples y prefiere 8 núcleos para cargas de trabajo de un solo subproceso. Al final, IIS fue un poco más rápido que todos los demás con 8 núcleos bajo carga alta, aunque todos los servidores estaban a la par.
Esto no es un error de medición, el error aquí no es más de +-1 ms. en retrasos y no más de +- 2-3 solicitudes por segundo para RPR.
Los resultados de que 8 núcleos tengan un peor rendimiento no son nada sorprendentes, muchos núcleos y SMT/Hyperthreading degradan enormemente el rendimiento si tenemos un marco de tiempo en el que tenemos que completar todo el proceso.
Fuente: habr.com