Passenger, gestion des ressources avec plus de 6 applications

Erreur type rencontrée : This website is under heavy load, too many requests

Too many requests ?

Passenger contient dans sa configuration un paramètre PassengerMaxRequestQueueSize définissant le nombre de requêtes en attente à 100 par défaut.
Contrairement à ce que l’on pourrait penser, rallonger cette file d’attente n’est pas une bonne idée. Le serveur a une capacité à traiter un volume de requêtes simultanées donné. Lorsqu’il ne peut plus en traiter, les clients doivent alors patienter dans la file d’attente : lorsque le serveur a placé 100 requêtes en attente, toutes les prochaines recevront l’erreur « 503 Service Unavailable ».
Cette file d’attente est une sorte de tampon lors de montée en charge momentanée et non une solution durable. On peut en effet s’attendre à voir le temps d’attente devenir de plus en plus long à mesure que la file s’allonge, et des clients seront alors tentés de quitter ou de rafraichir leur page, augmentant le nombre de requêtes à traiter sans même en attendre la réponse.

Si le serveur ne peut plus faire face, il faut alors en changer ou augmenter ses ressources. Mais ce n’est pas la seule raison de l’apparition de notre erreur initiale.

Beaucoup d’appli, pool trop petit

Lorsque l’erreur « This website is under heavy load » apparait, vous pouvez soupçonner une autre cause qu’un nombre trop élevé de requêtes. C’est le cas si vous venez de lancer des actions gourmandes sur plusieurs applications, comme dans notre cas.

Ce qu’explique cet article c’est la manière dont Passenger gère des applications. Par nature, une application Rails ne peut gérer qu’une requête à la fois. Pour paralléliser le traitement des requêtes, Passenger créé des processus pour chaque nouvelle requête, dans lesquels l’application est lancée à nouveau.
passenger-request_load_balancing
Un processus ne peut donc traiter qu’une requête à la fois, mais Passenger n’attribue pas de limite de création de processus et il s’assure qu’au moins un processus reste toujours actif par application. Les processus inactifs depuis plus de 5 minutes sont éteints.

En revanche, Passenger définit une limite globale du nombre de processus actifs, par défaut de 6 processus, qui fait autorité sur tout autre paramètre de configuration. Cela signifie qu’avec 7 applications, Passenger passera son temps à jongler entre les processus actifs pour n’en garder que 6, éteignant un processus pour en démarrer un autre.

Par défaut, si une action telle qu’un import de données est lancée simultanément sur 6 applications, les 6 processus actifs ne peuvent plus être « tués » car ils sont en cours de traitement long et la queue va se remplir très rapidement. Le paramètre « passengermaxpoolsize » est donc à configurer en fonction du nombre d’applications que Passenger gère, selon vos besoins et la capacité du serveur.

Pour ne pas manquer de mémoire vive, la documentation conseille de garder 25% de la RAM totale pour l’OS. On divise les 75% de RAM restants par la consommation en RAM totale de toutes les applications (attention aux unités), ce qui indique combien de processus le serveur est en théorie capable d’exécuter.

Il est possible de surveiller la consommation en ressources de chaque application via la commande passenger-status. On y trouve la longueur courante de la queue, bien qu’il ne soit pas possible de la visualiser. Il est cependant possible d’afficher les requêtes en cours de traitement avec passenger-status --show=requests.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée.