NGINX 1.9.1 presenta una nueva característica que permite el uso de la opción de socket SO_REUSEPORT
, que está disponible en versiones más nuevas de muchos sistemas operativos, incluidos DragonFly BSD y Linux (versión de kernel 3.9 y posteriores). Esta opción de socket permite que varios sockets escuchen en la misma combinación de dirección IP y puerto. Luego, el kernel equilibra la carga de las conexiones entrantes entre los sockets.
Editor: para los usuarios de NGINX Plus, esta función es compatible con NGINX Plus versión 7 (R7) y versiones posteriores. Para obtener una descripción general de todas las nuevas características de esa versión, consulte Anuncio de NGINX Plus R7 en nuestro blog.
La opción de socket SO_REUSEPORT
tiene muchas aplicações potenciales en el mundo real. Otros servicios pueden usarlo para realizar actualizaciones sucesivas de ejecutables de forma sencilla (NGINX ya admite actualizaciones sucesivas a través de diferentes medios ). Para NGINX, habilitar esta opción de socket puede mejorar el rendimiento en ciertos escenarios al reducir la contención de bloqueo.
Como se muestra en la figura, cuando la opción SO_REUSEPORT
no está habilitada, un único socket de escucha notifica a los trabajadores sobre las conexiones entrantes y cada trabajador intenta tomar una conexión.
Con la opción SO_REUSEPORT
habilitada, hay varios escuchas de sockets para cada combinación de dirección IP y puerto, uno para cada proceso de trabajo. El núcleo determina qué oyente de socket disponible (y por implicación, qué trabajador) obtiene la conexión. Esto puede reducir la contención de bloqueo entre trabajadores que aceptan nuevas conexiones y mejorar el rendimiento en sistemas multinúcleo. Sin embargo, también puede significar que cuando un trabajador se detiene por una operación de bloqueo, el bloqueo afecta no sólo a las conexiones que el trabajador ya ha aceptado, sino también a las solicitudes de conexión que el núcleo ha asignado al trabajador desde que se bloqueó.
Para habilitar la opción de socket SO_REUSEPORT
, incluya el nuevo parámetro reuseport
en la directiva de escucha
para el tráfico HTTP o TCP (módulo de flujo ), como en estos ejemplos:
http { servidor { escuchar 80 reuseport ; nombre_servidor localhost; # ... } } stream { servidor { escuchar 12345 puerto de reutilización ; # ... } }
Incluir el parámetro reuseport
también deshabilita la directiva accept_mutex
para el socket, porque el mutex es redundante con reuseport
. Todavía puede valer la pena configurar accept_mutex
si hay puertos en los que no configura reuseport
.
reuseport
Ejecuté una prueba comparativa de wrk con 4 trabajadores NGINX en una instancia de AWS de 36 núcleos. Para eliminar los efectos de red, ejecuté el cliente y NGINX en el host local, y también hice que NGINX devolviera la cadena OK
en lugar de un archivo. Comparé tres configuraciones de NGINX: la predeterminada (equivalente a accept_mutex activado
), con accept_mutex desactivado
y con reuseport
. Como se muestra en la figura, reuseport
aumenta las solicitudes por segundo de 2 a 3 veces y reduce tanto la latencia como la desviación estándar de la latencia.
También ejecuté una prueba comparativa relacionada con el cliente y NGINX en hosts separados y con NGINX devolviendo un archivo HTML. Como se muestra en la siguiente tabla, con reuseport
la disminución de la latencia fue similar al punto de referencia anterior, y la desviación estándar disminuyó aún más drásticamente (casi diez veces). Otros resultados (no mostrados en la tabla) también fueron alentadores. Con reuseport
, la carga se distribuyó uniformemente entre los procesos de trabajo. En la condición predeterminada (equivalente a accept_mutex activado
), algunos trabajadores obtuvieron un mayor porcentaje de la carga y, con accept_mutex desactivado,
todos los trabajadores experimentaron una carga alta.
Latencia (ms) | Desviación estándar de latencia (ms) | Carga de CPU | |
---|---|---|---|
Por defecto | 15.65 | 26.59 | 0.3 |
accept_mutex desactivado |
15.59 | 26.48 | 10 |
informe de reutilización |
12.35 | 3.15 | 0.3 |
En estos puntos de referencia, la tasa de solicitudes de conexión es alta, pero las solicitudes no requieren un procesamiento extenso. Otras pruebas preliminares también indican que reuseport
mejora el rendimiento más cuando el tráfico coincide con este perfil. (El parámetro reuseport
no está disponible en la directiva listen
en el contexto de correo
, por ejemplo, porque el tráfico de correo electrónico definitivamente no coincide con el perfil). Le recomendamos que pruebe reuseport
para determinar si mejora el rendimiento en su implementación de NGINX, en lugar de aplicarlo de manera generalizada. Para obtener algunos consejos sobre cómo probar el rendimiento de NGINX, consulte la charla de Konstantin Pavlov en nginx.conf 2014.
Gracias a Yingqi Lu de Intel y Sepherosa Ziehau, quienes contribuyeron con una solución al proyecto NGINX que permite el uso de la opción de socket SO_REUSEPORT
. El equipo de NGINX combinó ideas de ambas contribuciones para crear lo que creemos es una solución ideal.
"Esta publicación de blog puede hacer referencia a productos que ya no están disponibles o que ya no reciben soporte. Para obtener la información más actualizada sobre los productos y soluciones F5 NGINX disponibles, explore nuestra familia de productos NGINX . NGINX ahora es parte de F5. Todos los enlaces anteriores de NGINX.com redirigirán a contenido similar de NGINX en F5.com.