Guía de dimensionamiento de NGINX Plus: cómo realizamos las pruebas

NGINX | 29 de noviembre de 2016

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

[Editor – Actualizamos periódicamente la guía de dimensionamiento para reflejar los cambios tanto en las funcionalidades de NGINX Plus como en los costes y el rendimiento del hardware. El enlace anterior siempre dirige a la versión más reciente de la guía.

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

La guía de dimensionamiento describe el rendimiento que puede esperar obtener al ejecutar NGINX Plus en servidores de distintos tamaños, junto con los costes estimados del hardware. Puede utilizarla para dimensionar adecuadamente las implementaciones de NGINX Plus y evitar, en la medida de lo posible, tanto el sobredimensionamiento —que supone un coste inmediato— como el infradimensionamiento —que puede causar problemas de rendimiento y generar costes a largo plazo—.

La guía de dimensionamiento ha suscitado mucho interés, así como preguntas sobre la metodología que utilizamos, tanto por parte de clientes como de otras personas interesadas en reproducir nuestros resultados. Esta entrada del blog ofrece una visión general de las pruebas que realizamos para obtener los resultados presentados en la guía de dimensionamiento. En ella se describen la topología que utilizamos, las pruebas que llevamos a cabo y cómo obtuvimos los precios indicados en la guía de dimensionamiento.

Nota: Aunque desarrollamos la guía de dimensionamiento específicamente para NGINX Plus, utilizamos NGINX Open Source para las pruebas, de modo que cualquiera pueda reproducirlas sin una suscripción a NGINX Plus. Las pruebas no utilizan ninguna de las funciones avanzadas de NGINX Plus, por lo que los resultados de NGINX Open Source y NGINX Plus son los mismos. La versión 1.9.7 de NGINX Open Source se corresponde aproximadamente con la versión 7 de NGINX Plus.

Sin embargo, para distinguir mejor el proxy inverso del servidor web de backend en la topología de pruebas, nos referimos al primero como NGINX Plus y al segundo como NGINX (Open Source).

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 sencilla y plana.

Se utilizó una topología estándar con tres equipos conectados en cadena para probar el rendimiento de NGINX Plus

Para generar tráfico desde el equipo cliente, utilizamos wrk, una herramienta de pruebas de rendimiento similar a ab (ApacheBench). Como se muestra en el diagrama, todo el tráfico se dirigió al proxy inverso de NGINX Plus, que reenvió las conexiones al servidor web backend de NGINX Open Source.

Hardware utilizado

Utilizamos el siguiente hardware para las pruebas.

Máquina CPU Red MemoriaCliente 2x Intel(R) Xeon(R) CPU E5‑2699 v3 a 2,30 GHz, 36 núcleos reales (o 72 con HT) 2x Intel XL710 40GbE QSFP+ (rev. 01) 16 GBProxy inverso 2x Intel(R) Xeon(R) CPU E5‑2699 v3 a 2,30 GHz, 36 núcleos reales (o 72 con HT) 4x Intel XL710 40GbE QSFP+ (rev. 01) 16 GBServidor web 2x Intel(R) Xeon(R) CPU E5‑2699 v3 a 2,30 GHz, 36 núcleos reales (o 72 con HT) 2x Intel XL710 40GbE QSFP+ (rev. 01) 16 GB

Software utilizado

Utilizamos el siguiente software para las pruebas:

La versión 4.0.0 de wrk que se ejecutaba en el equipo cliente generó el tráfico que NGINX procesó como proxy. La instalamos siguiendo estas instrucciones.
La versión 1.9.7 de NGINX Open Source se ejecutó en los equipos de proxy inverso y servidor web. La instalamos desde el repositorio oficial de nginx.org siguiendo estas instrucciones.
Ubuntu Linux 14.04.1 se ejecutaba en las tres máquinas.

Metodología de las pruebas

Probamos el rendimiento del servidor proxy inverso NGINX Plus con distintos números de CPU. Un proceso worker de NGINX Plus utiliza una sola CPU, por lo que, para medir el rendimiento con distintos números de CPU, variamos el número de procesos worker, repitiendo las pruebas con dos procesos worker, cuatro, ocho, etc. Para obtener una visión general de la arquitectura de NGINX, consulte nuestro blog.

Nota: Para establecer manualmente el número de procesos worker, utilice la directiva worker_processes. El valor predeterminado es auto, que indica a NGINX Plus que detecte el número de CPU y ejecute un proceso worker por cada 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 persistente. El proxy inverso procesa cada solicitud y la reenvía al servidor web a través de otra conexión persistente.
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 a través de una nueva conexión. El proxy inverso analiza las solicitudes y las reenvía al servidor web a través de una conexión persistente ya establecida. El servidor web devuelve 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 de los clientes, utilizamos wrk con las siguientes opciones:

La opción -c especifica el número de conexiones TCP que se deben crear. Para nuestras pruebas, lo establecimos en 50 conexiones.
La opción -d especifica durante cuánto tiempo se genera tráfico. Cada una de nuestras pruebas duró 3 minutos.
La opción -t especifica el número de hilos que se deben crear. Especificamos un único hilo.

Para aprovechar al máximo cada CPU, utilizamos taskset, que permite vincular un único proceso de wrk a una CPU. Este método ofrece resultados más uniformes que aumentar el número de hilos de wrk.

Solicitudes por segundo

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

for i in `seq 0 $(($(getconf _NPROCESSORS_ONLN) - 1))`; do    taskset -c $i wrk -t 1 -c 50 -d 180s http://Reverse-Proxy-Server-IP-address/1kb.bin &
done

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

Transacciones SSL/TLS por segundo

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

for i in `seq 0 $(($(getconf _NPROCESSORS_ONLN) - 1))`; do    taskset -c $i wrk -t 1 -c 50 -d 180s -H 'Connection: close' https://Reverse-Proxy-Server-IP-address/0kb.bin &
done

Esta prueba utiliza los mismos valores para -c, -d y -t que la prueba anterior, pero presenta dos diferencias importantes, ya que se centra en el procesamiento de conexiones SSL/TLS:

El cliente abre y cierra una conexión para cada solicitud (la opción -H establece la cabecera HTTP Connection: en 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:

for i in `seq 0 $(($(getconf _NPROCESSORS_ONLN) - 1))`; do    taskset -c $i wrk -t 1 -c 50 -d 180s http://Reverse-Proxy-Server-IP-address/1mb.bin &
done

La única diferencia con respecto a la primera prueba es el mayor tamaño del archivo, de 1 MB. Comprobamos que utilizar un archivo aún más grande (10 MB) no aumentaba el rendimiento global.

Varias tarjetas de red

En nuestras pruebas utilizamos varias tarjetas de red. El siguiente script, ligeramente modificado, garantizó que el tráfico se distribuyera uniformemente entre las dos tarjetas:

for i in `seq 0 $((($(getconf _NPROCESSORS_ONLN) - 1)/2))`; do    n=`echo $(($i+number-of-CPUs/2))`;
    taskset -c $i ./wrk -t 1 -c 50 -d 180s http://Reverse-Proxy-Server-IP-address-1/1kb.bin &
    taskset -c $n ./wrk -t 1 -c 50 -d 180s http://Reverse-Proxy-Server-IP-address-2/1kb.bin &
done

Precios

El último paso, una vez obtenidos los datos de rendimiento con distintos números de núcleos, fue determinar el coste de los servidores con las especificaciones correspondientes. Utilizamos los precios de servidores Dell PowerEdge con especificaciones similares a las del hardware Intel empleado en nuestras pruebas. El apéndice que figura a continuación incluye 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.

Apéndice

Configuraciones de hardware de Dell

Los precios de la guía de dimensionamiento corresponden a las siguientes configuraciones de hardware de Dell.

Nota: Los modelos de servidor con las especificaciones y los precios indicados estaban disponibles cuando realizamos las pruebas, pero pueden cambiar en el futuro.

Modelo de servidor Especificaciones PrecioDell PowerEdge R230 CPU: Intel Core i3-6100 de 2 núcleos a 3,7 GHz, 2C/4T
RAM: 4 GB
HDD: 500 GB
NIC: Intel X710 2×10 GbE 1200 $CPU: Intel® Xeon® E3-1220 v5 a 3,0 GHz, 4C/8T
RAM: 4 GB
HDD: 500 GB
NIC: Intel XL710 2×40 GbE 1400 $Dell PowerEdge R430 CPU: Intel® Xeon® E5-2630 v3 a 2,4 GHz, 8C/16T
RAM: 4 GB
HDD: 500 GB
NIC: Intel XL710 2×40 GbE 2200 $CPU: 2 Intel® Xeon® E5-2630 v3 a 2,4 GHz, 8C/16T
RAM: 8 GB
HDD: 500 GB
NIC: Intel XL710 2×40 GbE 3000 $Dell PowerEdge R630 CPU: 2 Intel® Xeon® E5-2697A v4 a 2,6 GHz, 16C/32T
RAM: 8 GB
HDD: 500 GB
NIC: Intel XL710 2×40 GbE 8000 $CPU: 2 Intel® Xeon® E5-2699 v3 a 2,3 GHz, 18C/36T
RAM: 8 GB
HDD: 500 GB
NIC: Intel XL710 2×40 GbE 11 000 $

Configuración de NGINX Plus como proxy inverso

Se utilizó la siguiente configuración en el proxy inverso NGINX Plus. Observe los dos conjuntos de directivas keepalive_timeout y keepalive_requests:

Para las pruebas de TPS de SSL/TLS, configuramos los valores de ambas directivas para que las conexiones permanecieran abiertas durante una sola solicitud, ya que el objetivo de esta prueba era determinar 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 de RPS, las directivas se ajustaron para mantener las conexiones abiertas durante el mayor tiempo posible.

Por lo demás, la configuración es bastante estándar para un servidor proxy inverso, con NGINX Plus actuando como proxy de un servidor web mediante la directiva proxy_pass.

user                 nginx;worker_processes     auto;
worker_rlimit_nofile 10240;
pid                  /var/run/nginx.pid;

events {
    worker_connections 10240;
    accept_mutex       off;
    multi_accept       off;
}

http {
    access_log    off;
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                    '$status $body_bytes_sent "$http_referer" '
                    '"$http_user_agent" "$http_x_forwarded_for" "$ssl_cipher" '
                    '"$ssl_protocol" ';

    sendfile on;

    # RPS tests
    keepalive_timeout  300s;     
    keepalive_requests 1000000;

    # SSL/TLS TPS tests
    #keepalive_timeout  0;  
    #keepalive_requests 1; 
  
    upstream webserver {
        server Web-Server-IP-address;
    }

    server {
        listen 80;
        listen 443 ssl backlog=102400 reuseport;

        ssl_certificate     /etc/nginx/ssl/rsa-cert.crt;
        ssl_certificate_key /etc/nginx/ssl/rsa-key.key;
        ssl_session_tickets off;
        ssl_session_cache   off;

        root /var/www/html;
            location / {
                proxy_pass http://webserver;
            }
        }
    }
}

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 establecido por la directiva root. Los archivos estáticos se generaron mediante dd; este ejemplo crea un archivo de 1 KB lleno de ceros:

dd if=/dev/zero of=1kb.bin bs=1KB count=1

La configuración:

user                 nginx;
worker_processes     auto;
worker_rlimit_nofile 10240;
pid                  /var/run/nginx.pid;

events {
    worker_connections 10240;
    accept_mutex       off;
    multi_accept       off;
}

http {
    access_log   off;
    include      /etc/nginx/mime.types;
    default_type application/octet-stream;

    log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                    '$status $body_bytes_sent "$http_referer" '
                    '"$http_user_agent" "$http_x_forwarded_for" "$ssl_cipher" '
                    '"$ssl_protocol" ';

    sendfile on;

    keepalive_timeout  300s;     
    keepalive_requests 1000000;

    server {
        listen 80;
        root /var/www/html;
    }
}