Guía de tallas de NGINX Plus: Cómo hicimos la prueba

A principios de este año, evaluamos el rendimiento de NGINX Plus y creamos una guía de dimensionamiento para implementarlo en servidores físicos. NGINX Open Source y NGINX Plus se utilizan ampliamente para el equilibrio de carga de capa 7 , también conocido como equilibrio de carga de aplicação .

[ Editor : Actualizamos la guía de tamaño periódicamente para reflejar los cambios en las capacidades de NGINX Plus y los costos y el rendimiento del hardware. El enlace de arriba siempre lleva a la guía más reciente.

Para obtener información sobre el rendimiento de NGINX y NGINX Plus como servidor web, consulte Prueba del rendimiento de los servidores web NGINX y NGINX Plus .]

La guía de tamaño describe el rendimiento que puede esperar lograr con NGINX Plus ejecutándose en varios tamaños de servidores, junto con los costos estimados del hardware. Puede utilizar la guía de dimensionamiento para especificar adecuadamente las implementaciones de NGINX Plus y evitar el exceso de aprovisionamiento (que le cuesta dinero inmediatamente) o el aprovisionamiento insuficiente (que puede causar problemas de rendimiento y costarle dinero a largo plazo) tanto como sea posible.

Hemos recibido mucho interés en la guía de tallas, junto con preguntas sobre la metodología que utilizamos, por parte de clientes y otras personas interesadas en reproducir nuestros resultados. Esta publicación de blog proporciona una descripción general de las pruebas que realizamos para lograr los resultados presentados en la guía de tallas. Cubre la topología que usamos, las pruebas que realizamos y cómo encontramos los precios que figuran en la guía de tamaño.

Nota : Aunque desarrollamos la guía de tamaño específicamente para NGINX Plus, utilizamos NGINX Open Source para las pruebas para que cualquiera pueda reproducir nuestras pruebas sin una suscripción a NGINX Plus. Las pruebas no ejercitan ninguna de las características mejoradas de NGINX Plus, por lo que los resultados para NGINX Open Source y NGINX Plus son los mismos. La versión 1.9.7 de código abierto de NGINX corresponde aproximadamente a NGINX Plus Release 7.

Sin embargo, para distinguir mejor el proxy inverso del servidor web backend en la topología de prueba, utilizamos NGINX Plus para el primero y NGINX (código abierto) para el segundo.

Topología

Todas las pruebas se realizaron utilizando tres máquinas independientes conectadas entre sí mediante enlaces duales de 40 GbE en una red de capa 2 simple y plana.

Para generar tráfico desde la máquina cliente, utilizamos wrk , una herramienta de prueba de rendimiento similar a ab (ApacheBench). Como se muestra en el diagrama, todo el tráfico se dirigió al proxy inverso NGINX Plus, que reenvió las conexiones al servidor web de código abierto NGINX.

Hardware usado

Utilizamos el siguiente hardware para la prueba.

Software utilizado

Utilizamos el siguiente software para las pruebas:

• La versión 4.0.0 de wrk que se ejecuta en la máquina cliente generó el tráfico que NGINX procesó. Lo instalamos según estas instrucciones .
• La versión 1.9.7 de NGINX Open Source se ejecutó en las máquinas del servidor web y del proxy inverso . Lo instalamos desde el repositorio oficial en nginx.org de acuerdo con estas instrucciones .
• Ubuntu Linux 14.04.1 se ejecutó en las tres máquinas.

Metodología de pruebas

Probamos el rendimiento del servidor proxy inverso NGINX Plus con diferentes cantidades de CPU. Un proceso de trabajo NGINX Plus consume una sola CPU, por lo que para medir el rendimiento de diferentes cantidades de CPU variamos la cantidad de procesos de trabajo , repitiendo las pruebas con dos procesos de trabajo , cuatro, ocho, etc. Para obtener una descripción general de la arquitectura NGINX, consulte nuestro blog .

Nota : Para establecer manualmente el número de procesos de trabajo , utilice la directivaworker_processes . El valor predeterminado es auto , que le indica a NGINX Plus que detecte la cantidad de CPU y ejecute un proceso de trabajo por CPU.

Métricas de rendimiento

Medimos las siguientes métricas:

• Solicitudes por segundo (RPS) : mide la capacidad de procesar solicitudes HTTP. En nuestras pruebas, cada cliente envía solicitudes de un archivo de 1 KB a través de una conexión keepalive. El proxy inverso procesa cada solicitud y la reenvía al servidor web a través de otra conexión keepalive.
• Transacciones SSL/TLS por segundo (TPS) : mide la capacidad de procesar nuevas conexiones SSL/TLS. En nuestras pruebas, cada cliente envía una serie de solicitudes HTTPS, cada una en una nueva conexión. El proxy inverso analiza las solicitudes y las reenvía al servidor web a través de una conexión keepalive establecida. El servidor web envía una respuesta de 0 bytes para cada solicitud.
• Rendimiento : mide el rendimiento que NGINX Plus puede mantener al servir archivos de 1 MB a través de HTTP.

Ejecución de pruebas

Para generar todo el tráfico del cliente, utilizamos wrk con las siguientes opciones:

• La opción -c especifica el número de conexiones TCP a crear. Para nuestras pruebas, lo configuramos en 50 conexiones.
• La opción -d especifica durante cuánto tiempo generar tráfico. Ejecutamos nuestras pruebas durante 3 minutos cada una.
• La opción -t especifica el número de subprocesos a crear. Especificamos un solo hilo.

Para ejercitar completamente cada CPU, usamos tasket , que puede anclar un solo proceso wrk a una CPU. Este método produce resultados más consistentes que aumentar el número de subprocesos wrk .

Solicitudes por segundo

Para medir las solicitudes por segundo (RPS), ejecutamos el siguiente script:

para i en `seq 0 $(($(getconf _NPROCESSORS_ONLN) - 1))`; hacer tasket -c $i wrk -t 1 -c 50 -d 180s http:// Dirección IP del servidor proxy inverso /1kb.bin y listo

Esta prueba generó una copia de wrk por CPU, 36 en total para nuestra máquina cliente. Cada copia creó 50 conexiones TCP y realizó solicitudes continuas de un archivo de 1 KB sobre ellas durante 3 minutos (180 segundos).

Transacciones SSL/TLS por segundo

Para medir las transacciones SSL/TLS por segundo (TPS), ejecutamos el siguiente script:

para i en `seq 0 $(($(getconf _NPROCESSORS_ONLN) - 1))`; hacer tasket -c $i wrk -t 1 -c 50 -d 180s -H 'Conexión: cerrada' https:// Dirección IP del servidor proxy inverso /0kb.bin y listo

Esta prueba utiliza los mismos valores para -c , -d y -t que la prueba anterior, pero difiere en dos formas notables porque el foco está en el procesamiento de conexiones SSL/TLS:

• El cliente abre y cierra una conexión para cada solicitud (la opción -H establece el encabezado HTTP Connection: close ).
• El archivo solicitado tiene un tamaño de 0 (cero) bytes en lugar de 1 KB.

Rendimiento

Para medir el rendimiento, ejecutamos el siguiente script:

para i en `seq 0 $(($(getconf _NPROCESSORS_ONLN) - 1))`; hacer tasket -c $i wrk -t 1 -c 50 -d 180s http:// Dirección IP del servidor proxy inverso /1mb.bin y listo

La única diferencia con la primera prueba es el tamaño del archivo, que es mayor, de 1 MB. Descubrimos que utilizar un tamaño de archivo incluso mayor (10 MB) no aumentó el rendimiento general.

Varias tarjetas de red

En nuestras pruebas utilizamos múltiples tarjetas de red. El siguiente script ligeramente modificado garantizó que el tráfico se distribuyera de manera uniforme entre las dos tarjetas:

para i en `seq 0 $((($(getconf _NPROCESSORS_ONLN) - 1)/2))`; hacer n=`echo $(($i+ número-de-CPUs/2 ))`; conjunto-de-tareas -c $i ./wrk -t 1 -c 50 -d 180s http:// Dirección-IP-del-Servidor-Proxy-Inverso-1 /1kb.bin & conjunto-de-tareas -c $n ./wrk -t 1 -c 50 -d 180s http:// Dirección-IP-del-Servidor-Proxy-Inverso-2 /1kb.bin & hecho

Precios

El paso final, una vez que tuvimos números de rendimiento con diferentes números de núcleos, fue determinar el costo de los servidores con las especificaciones correspondientes. Utilizamos precios de servidores Dell PowerEdge con especificaciones similares a las del hardware Intel que usamos en nuestras pruebas. El apéndice a continuación tiene una lista completa de materiales para cada servidor, junto con la configuración completa de NGINX tanto para el proxy inverso como para el servidor web .

Anexo

Configuraciones de hardware de Dell

Los precios en la guía de tamaños son para las siguientes configuraciones de hardware de Dell.

Nota : Los modelos de servidor con las especificaciones y precios indicados estaban disponibles en el momento en que realizamos nuestras pruebas, pero están sujetos a cambios en el futuro.

Configuración del proxy inverso NGINX Plus

La siguiente configuración se utilizó en el proxy inverso NGINX Plus. Tenga en cuenta los dos conjuntos de directivas keepalive_timeout y keepalive_requests :

• Para las pruebas TPS SSL/TLS, establecemos los valores para ambas directivas de modo que las conexiones permanezcan abiertas para una sola solicitud, ya que el objetivo de esa prueba es ver cuántas conexiones SSL/TLS por segundo puede procesar NGINX Plus. También se deshabilitó el almacenamiento en caché de sesiones SSL/TLS.
• Para las pruebas RPS, las directivas se ajustaron para mantener las conexiones activas durante el mayor tiempo posible.

La configuración es una configuración de servidor proxy inverso bastante estándar, con NGINX Plus haciendo proxy a un servidor web mediante la directiva proxy_pass .

usuario nginx;procesos_de_trabajador automático; archivo_de_límite_de_trabajador 10240; pid /var/run/nginx.pid; eventos { conexiones_de_trabajador 10240; aceptar_mutex desactivado; aceptar_múltiples desactivado; } http { registro_de_acceso desactivado; incluir /etc/nginx/mime.types; tipo_predeterminado aplicação/octet-stream; formato_de_registro principal '$dirección_remota - $usuario_remoto [$tiempo_local] "$solicitud" ' '$estado $bytes_del_cuerpo_enviados "$http_referer" ' '"$agente_de_usuario_http" "$http_x_reenviado_para" "$cifrado_ssl" ' '"$protocolo_ssl" '; enviar_archivo activado; # Pruebas RPS tiempo_de_espera_mantener_activo 300 s; solicitudes_mantener_activo 1000000; # Pruebas TPS SSL/TLS #keepalive_timeout 0; #keepalive_requests 1; servidor web ascendente { servidor dirección IP del servidor web ; } servidor { escuchar 80; escuchar 443 backlog ssl=102400 puerto de reutilización; certificado_ssl /etc/nginx/ssl/rsa-cert.crt; clave_certificado_ssl /etc/nginx/ssl/rsa-key.key; tickets_ssl_session_desactivados; caché_ssl_session_desactivado; raíz /var/www/html; ubicación / { contraseña_proxy http://servidor_web; } } } }

Configuración del servidor web NGINX

La siguiente configuración se utilizó en el servidor web NGINX. Sirve archivos estáticos desde /var/www/html/ , según lo configurado por la directiva root . Los archivos estáticos se generaron utilizando dd ; este ejemplo crea un archivo de 1 KB de ceros:

dd si=/dev/cero de=1kb.bin bs=1KB conteo=1

La configuración:

usuario nginx;
procesos_de_trabajo automáticos;
trabajador_rlimit_nofile 10240;
pid /var/run/nginx.pid;

eventos {
conexiones_de_trabajador 10240;
aceptar_mutex desactivado;
multi_accept desactivado;
}

http {
acceso_log desactivado;
incluir /etc/nginx/mime.types;
aplicação de tipo predeterminado /octet-stream;

formato de registro principal '$dirección_remota - $usuario_remoto [$hora_local] "$solicitud" '
'$estado $body_bytes_sent "$http_referer"'
'"$http_user_agent" "$http_x_reenviado_para" "$ssl_cipher" '
'"$ssl_protocol" ';

enviar archivo activado;

tiempo de espera de mantenimiento 300 s;
keepalive_requests 1000000;

servidor {
escuchar 80;
raíz /var/www/html;
}
}

Para probar NGINX Plus usted mismo, comience hoy una prueba gratuita de 30 días o contáctenos para analizar sus casos de uso .