Réglage Keepalive pour Gunicorn derrière ELB sans Nginx

L'API REST de notre application est servie par Gunicorn ( pas derrière Nginx) fonctionnant sur des instances AWS EC2 avec une configuration typique de mise à l'échelle automatique / équilibrage de charge. Le délai d'inactivité de l'équilibreur de charge est de 60 secondes et le délai de maintien en vie de Gunicorn est de 2 secondes. Nous avons vu des 504 Gateway Timeoutréponses sporadiques de cette configuration. Selon Amazon docs , cela peut être dû au fait que le délai d'expiration du serveur est inférieur au paramètre de délai d'inactivité de l'équilibreur de charge:

Cause 2: instances enregistrées fermant la connexion à Elastic Load Balancing.

Solution 2: activez les paramètres de conservation sur vos instances EC2 et définissez le délai de conservation sur supérieur ou égal aux paramètres de délai d'inactivité de votre équilibreur de charge.

Avec Nginx, la valeur par défaut keepalive_timeoutest de 75 secondes, ce qui semble bien fonctionner avec les paramètres par défaut ELB. Cependant, les documents Gunicorn recommandent un keepaliveparamètre dans la plage de 1 à 5 secondes.

Est-il judicieux de ramener la durée de vie de Gunicorn à 75 secondes, ou y a-t-il une bonne raison de la maintenir en dessous de 5 secondes même si nous n'utilisons pas de proxy inverse devant elle?

Vous voudrez presque certainement augmenter le minuteur de keepalive selon la recommandation ELB, car ELB réutilise les connexions. Il les maintiendra jusqu'à l'expiration du délai d'expiration et si une autre demande arrive à l'ELB, il utilisera souvent l'une des connexions déjà ouvertes pour vous l'envoyer.

504 Gateway Timeout est une erreur étrange pour cette condition, mais il semble que c'est ce que ELB renvoie lorsque la réutilisation d'une connexion coïncide avec la fermeture prématurée du back-end.

La recommandation de 5 secondes pourrait avoir un sens si les navigateurs communiquaient directement avec le back-end, mais ce n'est pas le cas avec ELB, qui est lui-même un proxy inverse approprié lorsqu'il s'exécute en mode HTTP.