Configuración de Keepalive para Gunicorn detrás de ELB sin Nginx

La API REST de nuestra aplicación es atendida por Gunicorn ( no detrás de Nginx) que se ejecuta en instancias AWS EC2 con una configuración típica de escalado automático / equilibrio de carga. El tiempo de espera de inactividad del equilibrador de carga es de 60 segundos, y el tiempo de espera para mantener vivo de Gunicorn es de 2 segundos. Hemos estado viendo 504 Gateway Timeoutrespuestas esporádicas de esta configuración. Según los documentos de Amazon , esto puede deberse a que el tiempo de espera de mantenimiento del servidor es menor que la configuración de tiempo de espera inactivo del equilibrador de carga:

Causa 2: instancias registradas que cierran la conexión a Elastic Load Balancing.

Solución 2: habilite la configuración de mantenimiento de vida en sus instancias EC2 y establezca el tiempo de espera de mantenimiento de vida en mayor o igual que la configuración de tiempo de espera inactivo de su equilibrador de carga.

Con Nginx, el valor predeterminado keepalive_timeoutes 75 segundos, lo que aparentemente funciona bien con la configuración predeterminada de ELB. Sin embargo, los documentos de Gunicorn recomiendan una keepaliveconfiguración en el rango de 1-5 segundos.

¿Tiene sentido aumentar la capacidad de mantenimiento de Gunicorn a 75 segundos, o hay una buena razón para mantenerla por debajo de 5 segundos aunque no estemos usando un proxy inverso?

Seguramente querrá aumentar el temporizador de keepalive según la recomendación de ELB, porque ELB reutiliza las conexiones. Los retendrá hasta que expire el tiempo de espera y si llega otra solicitud al ELB, a menudo usará una de las conexiones ya abiertas para enviársela.

504 Gateway Timeout es un error extraño para esta condición, pero parece que eso es lo que ELB devuelve cuando la reutilización de una conexión coincide con el cierre prematuro del back-end.

La recomendación de 5 segundos podría tener sentido si los navegadores se comunicaban directamente con el back-end, pero ese no es el caso con ELB, que en sí mismo es un proxy inverso adecuado cuando se ejecuta en modo HTTP.