Optimización de NGINX para el rendimiento

NGINX es conocido como un equilibrador de carga , caché y servidor web de alto rendimiento, que impulsa más del 40% de los sitios web más activos del mundo. Para la mayoría de los casos de uso, las configuraciones predeterminadas de NGINX y Linux funcionan bien, pero lograr un rendimiento óptimo a veces requiere un poco de ajuste. En esta publicación de blog se analizan algunas de las configuraciones de NGINX y Linux que se deben tener en cuenta al ajustar un sistema.

Puedes ajustar casi cualquier configuración, pero esta publicación se concentra en las pocas configuraciones para las que el ajuste beneficia a la mayoría de los usuarios. Hay configuraciones que recomendamos cambiar solo si tiene un conocimiento profundo de NGINX y Linux, o según lo indiquen nuestros equipos de soporte o servicios profesionales , y no las cubrimos aquí. El equipo de Servicios Profesionales ha trabajado con algunos de los sitios web más activos del mundo para optimizar NGINX para obtener el máximo nivel de rendimiento y está disponible para trabajar con usted para aprovechar al máximo su implementación de NGINX o NGINX Plus.

INTRODUCCIÓN

Se supone una comprensión básica de la arquitectura NGINX y los conceptos de configuración. Esta publicación no intenta duplicar la documentación de NGINX, pero proporciona una descripción general de las diversas opciones y enlaces a la documentación relevante.

Una buena regla a seguir al realizar ajustes es cambiar una configuración a la vez y volver al valor predeterminado si el cambio no mejora el rendimiento.

Comenzamos con una discusión sobre el ajuste de Linux, porque el valor de algunas configuraciones del sistema operativo determina cómo ajusta su configuración de NGINX.

Ajuste de su configuración de Linux

Las configuraciones de los kernels Linux modernos (2.6+) son adecuadas para la mayoría de los propósitos, pero cambiar algunas de ellas puede ser beneficioso. Revise el registro del kernel para ver si hay mensajes de error que indiquen que una configuración es demasiado baja y ajústela según las indicaciones. Aquí cubrimos solo aquellas configuraciones que tienen más probabilidades de beneficiarse del ajuste en cargas de trabajo normales. Para obtener detalles sobre cómo ajustar estas configuraciones, consulte la documentación de Linux.

La cola de trabajos pendientes

Las siguientes configuraciones se relacionan con las conexiones y cómo se ponen en cola. Si tiene una alta tasa de conexiones entrantes y obtiene niveles desiguales de rendimiento (por ejemplo, algunas conexiones parecen estancarse), cambiar estas configuraciones puede ayudar.

• net.core.somaxconn : el número máximo de conexiones que NGINX puede poner en cola para su aceptación. El valor predeterminado suele ser muy bajo, lo cual suele ser aceptable porque NGINX acepta conexiones muy rápidamente, pero puede ser conveniente aumentarlo si su sitio web tiene mucho tráfico. Si los mensajes de error en el registro del kernel indican que el valor es demasiado pequeño, auméntelo hasta que desaparezcan los errores.

  Nota:  Si lo establece en un valor mayor que 512, cambie el parámetro backlog a la directiva de escucha NGINX para que coincida.

• net.core. netdev_max_backlog : la velocidad a la que la tarjeta de red almacena en búfer los paquetes antes de entregarlos a la CPU. Aumentar el valor puede mejorar el rendimiento en máquinas con una gran cantidad de ancho de banda. Revise el registro del kernel para ver si hay errores relacionados con esta configuración y consulte la documentación de la tarjeta de red para obtener consejos sobre cómo cambiarla.

Descriptores de archivos

Los descriptores de archivos son recursos del sistema operativo que se utilizan para representar conexiones y archivos abiertos, entre otras cosas. NGINX puede utilizar hasta dos descriptores de archivos por conexión. Por ejemplo, si NGINX utiliza proxy, generalmente utiliza un descriptor de archivo para la conexión del cliente y otro para la conexión al servidor proxy, aunque esta relación es mucho menor si se utilizan keepalives HTTP. Para un sistema que atiende una gran cantidad de conexiones, es posible que sea necesario ajustar las siguientes configuraciones:

• sys.fs. file-max : el límite de todo el sistema para los descriptores de archivos
• nofile : el límite del descriptor de archivo del usuario, establecido en el archivo /etc/security/limits.conf

Puertos efímeros

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

• net.ipv4.ip_local_port_range : el inicio y el final del rango de valores de puerto. Si ves que te estás quedando sin puertos, aumenta el rango. Una configuración común son los puertos 1024 a 65000.

Ajuste de la configuración de NGINX

Las siguientes son algunas directivas NGINX que pueden afectar el rendimiento. Como se indicó anteriormente, solo analizamos directivas que usted puede ajustar de manera segura por su cuenta. Le recomendamos que no cambie la configuración de otras directivas sin la indicación del equipo de NGINX.

Procesos de trabajo

NGINX puede ejecutar múltiples procesos de trabajo, cada uno capaz de procesar una gran cantidad de conexiones simultáneas. Puede controlar la cantidad de procesos de trabajo y cómo manejan las conexiones con las siguientes directivas:

• worker_processes : la cantidad de procesos de trabajo de NGINX (el valor predeterminado es 1). En la mayoría de los casos, ejecutar un proceso de trabajo por núcleo de CPU funciona bien y recomendamos configurar esta directiva en automático para lograrlo. Hay ocasiones en las que es posible que desees aumentar este número, como cuando los procesos de trabajo tienen que realizar mucha E/S de disco.
• workers_connections – El número máximo de conexiones que cada proceso de trabajo puede manejar simultáneamente. El valor predeterminado es 512, pero la mayoría de los sistemas tienen 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 descubrirse mediante pruebas.

Conexiones Keepalive

Las conexiones Keepalive pueden tener un impacto importante en el rendimiento al reducir la sobrecarga de CPU y red necesarias para abrir y cerrar conexiones. NGINX finaliza todas las conexiones de clientes y crea conexiones separadas e independientes con los servidores ascendentes. NGINX admite keepalives tanto para clientes como para servidores ascendentes. Las siguientes directivas se relacionan con los keepalives del cliente:

• keepalive_requests : la cantidad de solicitudes que un cliente puede realizar en una única conexión keepalive. El valor predeterminado es 100, pero un valor mucho más alto puede ser especialmente útil para realizar pruebas con una herramienta de generación de carga, que generalmente envía una gran cantidad de solicitudes desde un solo cliente.
• keepalive_timeout : cuánto tiempo permanece abierta una conexión keepalive inactiva.

La siguiente directiva se relaciona con los keepalives ascendentes:

• keepalive : la cantidad de conexiones keepalive inactivas a un servidor ascendente que permanecen abiertas para cada proceso de trabajo. No hay ningún valor predeterminado.

Para habilitar conexiones keepalive a servidores ascendentes, también debe incluir las siguientes directivas en la configuración:

proxy_http_version 1.1; proxy_set_header Conexión "";

Registro de acceso

Registrar cada solicitud consume ciclos de CPU y 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 separada para cada entrada de registro, NGINX almacena en búfer una serie de entradas y las escribe en el archivo juntas 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 el búfer alcanza el valor de tamaño . Para que NGINX escriba el buffer después de una cantidad de tiempo específica, incluya el parámetro de tiempo flush= . Cuando se configuran ambos parámetros, NGINX escribe entradas en el archivo de registro cuando la siguiente entrada de registro no cabe en el búfer o las entradas en el búfer son más antiguas que el tiempo especificado, respectivamente. Las entradas de registro también se escriben cuando un proceso de trabajo vuelve a abrir sus archivos de registro o se apaga. Para deshabilitar el registro de acceso por completo, incluya el parámetro off en la directiva access_log .

Enviar archivo

La llamada al sistema sendfile() del sistema operativo copia datos de un descriptor de archivo a otro, logrando a menudo una copia cero, lo que puede acelerar las transferencias de datos TCP. Para permitir que NGINX lo use, incluya la directiva sendfile en el contexto http o en un contexto de servidor o ubicación . Luego, NGINX puede escribir contenido almacenado en caché o en disco en un socket sin cambiar el contexto al espacio del usuario, lo que hace que la escritura sea extremadamente rápida y consuma menos ciclos de CPU. Tenga en cuenta, sin embargo, que debido a que los datos copiados con sendfile() pasan por alto el espacio del usuario, no están sujetos a la cadena de procesamiento NGINX regular ni a los filtros que cambian el contenido, como gzip . Cuando un contexto de configuración incluye tanto la directiva sendfile como directivas que activan un filtro de cambio de contenido, NGINX deshabilita automáticamente sendfile para ese contexto.

Límites

Puede establecer varios límites que ayuden a evitar que los clientes consuman demasiados recursos, lo que puede afectar negativamente el rendimiento de su sistema, así como la seguridad y la experiencia del usuario. A continuación se presentan algunas de las directivas pertinentes:

• limit_conn y limit_conn_zone : limitan la cantidad de conexiones de cliente que NGINX acepta, por ejemplo, desde una única dirección IP. Configurarlas puede ayudar a evitar que clientes individuales abran demasiadas conexiones y consuman más de lo que les corresponde en recursos.
• limit_rate – Limita la velocidad a la que se transmiten las respuestas a un cliente, por conexión (de modo que los clientes que abren múltiples conexiones pueden consumir esta cantidad de ancho de banda para cada conexión). Establecer un límite puede evitar que el sistema se sobrecargue con ciertos clientes, garantizando 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 tiene los mismos beneficios que configurar limit_rate . También pueden mejorar la seguridad, especialmente para 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 su aplicação con solicitudes (como los bots en un ataque DDoS ).
• Parámetro max_conns de la directiva del servidor en un bloque de configuración ascendente : establece la cantidad máxima de conexiones simultáneas aceptadas por un servidor en un grupo ascendente. 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.
• cola (NGINX Plus): crea una cola en la que se colocan las solicitudes cuando todos los servidores disponibles en el grupo ascendente han alcanzado su límite max_conns . Esta directiva establece el número máximo de solicitudes en la cola y, opcionalmente, el tiempo máximo que esperan (60 segundos por defecto) antes de que se devuelva un error. Las solicitudes no se ponen en cola si se omite esta directiva.

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

Algunas características adicionales de NGINX que se pueden usar para aumentar el rendimiento de una aplicação web realmente no entran dentro del título de ajuste, pero vale la pena mencionarlas porque su impacto puede ser considerable. Incluyen almacenamiento en caché y compresión.

Almacenamiento en caché

Al habilitar el almacenamiento en caché en una instancia NGINX que equilibra la carga de un conjunto de servidores web o de aplicação , puede mejorar drásticamente el tiempo de respuesta a los clientes y, al mismo tiempo, reducir drásticamente la carga en los servidores back-end. El almacenamiento en caché es un tema en sí mismo y no intentaremos cubrirlo aquí. Consulte la Guía de administración de NGINX Plus .

Compresión

Comprimir las respuestas enviadas a los clientes puede reducir en gran medida su tamaño, de modo que utilicen menos ancho de banda de red. Sin embargo, dado que la compresión de datos consume recursos de la CPU, es más útil cuando realmente vale 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:

• Evaluación comparativa de NGINX: Mayor precisión y resultados significativos (seminario web a pedido)
• Documentación de referencia de NGINX en nginx.org
• Comparar modelos NGINX
• Especificaciones técnicas de NGINX Plus

Para probar NGINX Plus, comience hoy su prueba gratuita de 30 días o contáctenos para una demostración.