Fragmentación de sockets en NGINX versión 1.9.1

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ó.

Configuración de la fragmentación de sockets

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 .

Evaluación comparativa del rendimiento con 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.

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.

Expresiones de gratitud

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.