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


15

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?

Réponses:


16

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.


Merci, c'est ce que je soupçonnais. Je vais essayer ce changement cette semaine et marquer votre réponse si tout se passe bien :)
handsofaten

Nous avons fusionné le changement il y a environ une semaine et les 504 sont devenus beaucoup moins courants (quelques fois par semaine au lieu de quelques centaines de fois par semaine).
handsofaten
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.