Optimización del rendimiento de NGINX

NGINX | 10 de octubre de 2014

Rick NelsonVicepresidente regional de Ingeniería de Soluciones

NGINX es ampliamente conocido por ser un balanceador de carga de alto rendimiento, una caché y un servidor web, y por sustentar más del 40 % de los sitios web con más tráfico del mundo. En la mayoría de los casos de uso, la configuración predeterminada de NGINX y Linux funciona bien, pero para lograr un rendimiento óptimo a veces es necesario realizar algunos ajustes. En esta entrada del blog se analizan algunos de los parámetros de NGINX y Linux que conviene tener en cuenta al optimizar un sistema.

Puede ajustar prácticamente cualquier parámetro, pero esta publicación se centra en los pocos cuyo ajuste beneficia a la mayoría de los usuarios. Hay parámetros que recomendamos cambiar únicamente si tiene un conocimiento profundo de NGINX y Linux, o siguiendo las indicaciones de nuestros equipos de Soporte o Servicios profesionales, y que no abordamos aquí. El equipo de Servicios profesionales ha trabajado con algunos de los sitios web con más tráfico del mundo para ajustar NGINX y obtener el máximo rendimiento, y está a su disposición para ayudarle a sacar el máximo partido a su implementación de NGINX o NGINX Plus.

Introducción

Se presupone un conocimiento básico de la arquitectura de NGINX y de los conceptos de configuración. Este artículo no pretende reproducir la documentación de NGINX, sino ofrecer una visión general de las distintas opciones y enlaces a la documentación pertinente.

Una buena regla que conviene seguir al realizar ajustes es cambiar una opción cada vez y restablecerla a su valor predeterminado si el cambio no mejora el rendimiento.

Comenzamos analizando el ajuste de Linux, ya que el valor de algunos parámetros del sistema operativo determina cómo debe ajustar la configuración de NGINX.

Optimización de la configuración de Linux

La configuración de los kernels de Linux modernos (2.6 y posteriores) es adecuada para la mayoría de los usos, aunque modificar algunos parámetros puede resultar beneficioso. Consulte el registro del kernel para detectar mensajes de error que indiquen que el valor de algún parámetro es demasiado bajo y ajústelo según las recomendaciones. Aquí solo se abordan los parámetros cuyo ajuste tiene más probabilidades de resultar beneficioso con cargas de trabajo normales. Para obtener información detallada sobre cómo ajustar estos parámetros, consulte la documentación de Linux.

La cola de conexiones pendientes

Los siguientes ajustes están relacionados con las conexiones y con la forma en que se ponen en cola. Si recibe un gran número de conexiones entrantes y observa niveles de rendimiento irregulares (por ejemplo, algunas conexiones parecen quedarse bloqueadas), cambiar estos ajustes puede resultar útil.

net.core.somaxconn – El número máximo de conexiones que pueden ponerse en cola para que NGINX las acepte. El valor predeterminado suele ser muy bajo, lo que normalmente resulta aceptable porque NGINX acepta las conexiones con gran rapidez, pero puede ser conveniente aumentarlo si su sitio web recibe mucho tráfico. Si los mensajes de error del registro del kernel indican que el valor es demasiado bajo, auméntelo hasta que dejen de aparecer los errores.Nota: Si establece un valor superior a 512, cambie el parámetro backlog de la directiva listen de NGINX para que coincida.
net.core.netdev_max_backlog – La velocidad a la que la tarjeta de red almacena los paquetes en el búfer antes de transferirlos a la CPU. Aumentar este valor puede mejorar el rendimiento en equipos con un gran ancho de banda. Compruebe si hay errores relacionados con este ajuste en el registro del kernel y consulte la documentación de la tarjeta de red para obtener recomendaciones sobre cómo modificarlo.

Descriptores de archivo

Los descriptores de archivo son recursos del sistema operativo que se utilizan para representar, entre otras cosas, conexiones y archivos abiertos. NGINX puede utilizar hasta dos descriptores de archivo por conexión. Por ejemplo, cuando NGINX actúa como proxy, suele utilizar un descriptor de archivo para la conexión del cliente y otro para la conexión con el servidor de destino, aunque esta proporción es mucho menor si se utilizan conexiones persistentes HTTP. En un sistema que gestione un gran número de conexiones, puede ser necesario ajustar las siguientes opciones:

sys.fs.file-max – El límite de descriptores de archivo para todo el sistema
nofile – El límite de descriptores de archivo del usuario, configurado en el archivo /etc/security/limits.conf file

Puertos efímeros

Cuando NGINX actúa como proxy, cada conexión a un servidor ascendente utiliza un puerto temporal, o efímero. Puede que le interese cambiar esta configuración:

net.ipv4.ip_local_port_range – Los valores inicial y final del intervalo de puertos. Si observa que se está quedando sin puertos, amplíe el intervalo. Una configuración habitual es utilizar los puertos del 1024 al 65000.

Optimización de la configuración de NGINX

A continuación se indican algunas directivas de NGINX que pueden afectar al rendimiento. Como se ha señalado anteriormente, solo abordamos aquellas directivas que puede ajustar por su cuenta de forma segura. Le recomendamos que no cambie la configuración de otras directivas sin las indicaciones del equipo de NGINX.

Procesos de trabajo

NGINX puede ejecutar varios procesos de trabajo, cada uno capaz de procesar un gran número de conexiones simultáneas. Puede controlar el número de procesos de trabajo y cómo gestionan las conexiones mediante las siguientes directivas:

worker_processes – El número de procesos de trabajo de NGINX (el valor predeterminado es 1). En la mayoría de los casos, ejecutar un proceso de trabajo por cada núcleo de CPU funciona bien, por lo que recomendamos establecer esta directiva en auto para conseguirlo. En ocasiones, puede ser conveniente aumentar este número, por ejemplo, cuando los procesos de trabajo tienen que realizar muchas operaciones de E/S en disco.
worker_connections – El número máximo de conexiones que cada proceso de trabajo puede gestionar simultáneamente. El valor predeterminado es 512, pero la mayoría de los sistemas disponen de recursos suficientes para admitir un número mayor. La configuración adecuada depende del tamaño del servidor y de la naturaleza del tráfico, y puede determinarse mediante pruebas.

Conexiones persistentes

Conexiones persistentes pueden tener un gran impacto en el rendimiento al reducir la sobrecarga de la CPU y de la red necesaria para abrir y cerrar conexiones. NGINX finaliza todas las conexiones de los clientes y crea conexiones separadas e independientes con los servidores ascendentes. NGINX admite conexiones persistentes tanto para los clientes como para los servidores ascendentes. Las siguientes directivas están relacionadas con las conexiones persistentes de los clientes:

keepalive_requests – El número de solicitudes que un cliente puede realizar a través de una única conexión persistente. El valor predeterminado es 100, pero un valor mucho mayor puede resultar especialmente útil para realizar pruebas con una herramienta de generación de carga, que generalmente envía un gran número de solicitudes desde un único cliente.
keepalive_timeout – El tiempo que una conexión keepalive inactiva permanece abierta.

La siguiente directiva está relacionada con las conexiones persistentes con servidores upstream:

keepalive – El número de conexiones persistentes inactivas con un servidor ascendente que permanecen abiertas para cada proceso de trabajo. No hay ningún valor predeterminado.

Para habilitar las conexiones persistentes con los servidores ascendentes, también debe incluir las siguientes directivas en la configuración:

proxy_http_version 1.1;proxy_set_header Connection "";

Registro de acceso

Registrar cada solicitud consume ciclos tanto de CPU como de E/S, y una forma de reducir el impacto es habilitar el almacenamiento en búfer del registro de acceso. Con el almacenamiento en búfer, en lugar de realizar una operación de escritura independiente para cada entrada del registro, NGINX acumula una serie de entradas y las escribe juntas en el archivo en una sola operación.

Para habilitar el almacenamiento en búfer del registro de acceso, incluya el parámetro buffer=size en la directiva access_log; NGINX escribe el contenido del búfer en el registro cuando este alcanza el valor de size. Para que NGINX escriba el búfer después de un periodo de tiempo determinado, incluya el parámetro flush=time. Cuando se establecen ambos parámetros, NGINX escribe las entradas en el archivo de registro cuando la siguiente entrada no cabe en el búfer o cuando las entradas del búfer superan la antigüedad especificada, respectivamente. Las entradas del registro también se escriben cuando un proceso de trabajo vuelve a abrir sus archivos de registro o se cierra. Para deshabilitar por completo el registro de acceso, incluya el parámetro off en la directiva access_log.

Sendfile

La llamada al sistema sendfile() del sistema operativo copia datos de un descriptor de archivo a otro, a menudo sin realizar copias, lo que puede acelerar las transferencias de datos TCP. Para permitir que NGINX la utilice, incluya la directiva sendfile en el contexto http o en un contexto server o location. De este modo, NGINX puede enviar contenido almacenado en caché o en disco a través de un socket sin ningún cambio de contexto al espacio de usuario, lo que hace que la escritura sea extremadamente rápida y consuma menos ciclos de CPU. Sin embargo, tenga en cuenta que, dado que los datos copiados mediante sendfile() omiten el espacio de usuario, no pasan por la cadena de procesamiento habitual de NGINX ni por los filtros que modifican el contenido, como gzip. Cuando un contexto de configuración incluye tanto la directiva sendfile como directivas que activan un filtro que modifica el contenido, NGINX desactiva automáticamente sendfile para ese contexto.

Límites

Puede establecer varios límites para evitar que los clientes consuman demasiados recursos, lo que podría afectar negativamente al rendimiento del sistema, así como a la seguridad y a la experiencia del usuario. Estas son algunas de las directivas pertinentes:

limit_conn y limit_conn_zone – Limitan el número de conexiones de clientes que acepta NGINX, por ejemplo, desde una única dirección IP. Configurarlas puede ayudar a evitar que clientes individuales abran demasiadas conexiones y consuman más recursos de los que les corresponden.
limit_rate – Limita la velocidad a la que se transmiten las respuestas a un cliente por conexión (por lo que los clientes que abran varias conexiones pueden consumir esta cantidad de ancho de banda en cada conexión). Establecer un límite puede evitar que determinados clientes sobrecarguen el sistema, lo que garantiza una calidad de servicio más uniforme para todos los clientes.
limit_req y limit_req_zone – Limitan la tasa de solicitudes procesadas por NGINX, lo que ofrece las mismas ventajas que configurar limit_rate. También pueden mejorar la seguridad, especialmente en las páginas de inicio de sesión, al limitar la tasa de solicitudes a un valor razonable para los usuarios humanos, pero demasiado lento para los programas que intentan saturar la aplicación con solicitudes (como los bots en un ataque DDoS).
max_conns parámetro de la directiva server en un bloque de configuración upstream – Establece el número máximo de conexiones simultáneas que acepta un servidor de un grupo de servidores ascendentes. Imponer un límite puede ayudar a evitar que los servidores ascendentes se sobrecarguen. Establecer el valor en 0 (cero, el valor predeterminado) significa que no hay límite.
queue (NGINX Plus): crea una cola en la que se colocan las solicitudes cuando todos los servidores disponibles del grupo de servidores ascendentes han alcanzado su límite de max_conns. Esta directiva establece el número máximo de solicitudes en la cola y, opcionalmente, el tiempo máximo que pueden esperar (60 segundos de forma predeterminada) antes de que se devuelva un error. Si se omite esta directiva, las solicitudes no se ponen en cola.

El almacenamiento en caché y la compresión pueden mejorar el rendimiento

Algunas funciones adicionales de NGINX que pueden utilizarse para mejorar el rendimiento de una aplicación web no encajan realmente en la categoría de optimización, pero merece la pena mencionarlas porque su impacto puede ser considerable. Entre ellas se incluyen el almacenamiento en caché y la compresión.

Almacenamiento en caché

Al habilitar el almacenamiento en caché en una instancia de NGINX que equilibra la carga de un conjunto de servidores web o de aplicaciones, puede mejorar drásticamente el tiempo de respuesta a los clientes y, al mismo tiempo, reducir de forma considerable la carga de los servidores backend. El almacenamiento en caché es un tema con entidad propia y no trataremos de abordarlo aquí. Consulte la Guía de administración de NGINX Plus.

Compresión

Comprimir las respuestas enviadas a los clientes puede reducir considerablemente su tamaño, por lo que consumen menos ancho de banda de red. Sin embargo, dado que la compresión de datos consume recursos de CPU, resulta especialmente útil cuando realmente merece la pena reducir el uso del ancho de banda. Es importante tener en cuenta que no debe habilitar la compresión para objetos que ya estén comprimidos, como los archivos JPEG. Para obtener más información, consulte la Guía de administración de NGINX Plus.

Para obtener más información, consulte: