Démarrage lent du serveur lors de l'utilisation de Phusion Passenger et Rails

87

Pour sauter dans le wagon à bande de Phusion Passenger, nous avons configuré un serveur de préparation pour une petite application de rails afin de tester les choses.

Jusqu'à présent, il a été très agréable à utiliser, cela facilite l'installation / la configuration et le déploiement d'applications. Le problème est que le site que nous utilisons n'est pas très souvent touché et qu'il semble arrêter les serveurs en arrière-plan. Cela signifie que lorsque quelqu'un se rend sur le site, il attend très longtemps avant de démarrer un nouveau serveur pour traiter la demande. Nous avons lu la documentation, essayé plusieurs configurations différentes (modes smart / smart-lv2, passageridletime, etc.) et n'avons toujours pas trouvé de vraie solution.

Après avoir parcouru les résultats de Google, nous ne pouvons pas vraiment trouver d'informations utiles. Actuellement, nous avons une tâche cron qui fait une requête de temps en temps pour tenter de maintenir les serveurs en marche.

Quelqu'un d'autre rencontre-t-il ce problème et avez-vous des conseils pour une solution?

ruby-on-rails  deployment  passenger  phusion 
— tsdbrown
source
J'ai également trouvé cette pépite sur le site Passenger Doc: modrails.com/documentation
— ...
@dewrich J'ai trouvé un outil ( wekkars.com ) qui fait exactement ce que fait votre cronjob
— SteenhouwerD

Réponses:

119

Ce qui se passe, c'est que votre Application et / ou ApplicationSpawners s'arrête en raison d'un délai d'expiration. Pour traiter votre nouvelle demande, Passenger doit démarrer une nouvelle copie de votre application, ce qui peut prendre plusieurs secondes, même sur une machine rapide. Pour résoudre le problème, il existe quelques options de configuration Apache que vous pouvez utiliser pour maintenir votre application en vie.

Voici précisément ce que j'ai fait sur mes serveurs. PassengerSpawnMethod et PassengerMaxPreloaderIdleTime sont les options de configuration les plus importantes dans votre situation.

# Speeds up spawn time tremendously -- if your app is compatible. 
# RMagick seems to be incompatible with smart spawning
# Older versions of Passenger called this RailsSpawnMethod
PassengerSpawnMethod smart

# Keep the application instances alive longer. Default is 300 (seconds)
PassengerPoolIdleTime 1000

# Keep the spawners alive, which speeds up spawning a new Application
# listener after a period of inactivity at the expense of memory.
# Older versions of Passenger called this RailsAppSpawnerIdleTime
PassengerMaxPreloaderIdleTime 0

# Just in case you're leaking memory, restart a listener 
# after processing 5000 requests
PassengerMaxRequests 5000

En utilisant le mode d'apparition "intelligent" et en désactivant PassengerMaxPreloaderIdleTime, Passenger gardera 1 copie de votre application en mémoire à tout moment (après la première requête après le démarrage d'Apache). Les Applicationauditeurs individuels seront forkédités de cette copie, qui est une opération super bon marché. Cela se produit si rapidement que vous ne pouvez pas dire si votre application a dû générer un auditeur ou non.

Si votre application est incompatible avec le frai intelligent, je vous recommande de conserver un grand PassengerPoolIdleTime et de frapper votre site périodiquement en utilisant curl et un cronjob ou monit ou quelque chose pour garantir que l'auditeur reste en vie.

Le guide de l'utilisateur passager est une référence formidable pour ces options de configuration et d'autres.

modifier : Si votre application est incompatible avec le frai intelligent, il existe de nouvelles options très intéressantes

# Automatically hit your site when apache starts, so that you don't have to wait
# for the first request for passenger to "spin up" your application. This even
# helps when you have smart spawning enabled. 
PassengerPreStart http://myexample.com/
PassengerPreStart http://myexample2.com:3500/

# the minimum number of application instances that must be kept around whenever 
# the application is first accessed or after passenger cleans up idle instances
# With this option, 3 application instances will ALWAYS be available after the
# first request, even after passenger cleans up idle ones
PassengerMinInstances 3

Ainsi, si vous combinez PassengerPreStart et PassengerMinInstances, Passenger lancera 3 instances immédiatement après le chargement d'Apache, et gardera toujours au moins 3 instances actives, de sorte que vos utilisateurs verront rarement (voire jamais) un retard.

Ou, si vous utilisez déjà le frai intelligent (recommandé) PassengerMaxPreloaderIdleTime 0, vous pouvez ajouter PassengerPreStartpour obtenir l'avantage supplémentaire d'un démarrage immédiat.

Un grand merci aux héros de phusion.nl !

— John Douthat
source
Merci beaucoup pour votre réponse. Je pense que nous avons essayé la plupart de ces paramètres, mais peut-être pas dans la bonne combinaison. Je vais faire des tests demain et revenir.
— tsdbrown
C'est génial. J'avais le même problème avec mon installation Nginx / Phusion Passenger et cela m'a énormément aidé.
— Scott Anderson
J'ai essayé cette configuration et je ne vois aucune amélioration des performances, mais notre application utilise RMagick. Existe-t-il des solutions de contournement pour cela? Pourquoi cela ne fonctionne-t-il pas avec RMagick?
— Chip Castle du
1
RailsSpawnMethodest obsolète au profit de PassengerSpawnMethod modrails.com/documentation/…
— paulus
Salut, j'ai le même problème et j'aimerais essayer cette configuration, mais je ne sais pas où cette configuration doit être placée. Merci!
— joseramonc
41

Juste au cas où des utilisateurs de serveurs nginx trébucheraient sur cette question, les directives «PassengerMaxRequests» et «PassengerStatThrottleRate» ne se traduisent pas en nginx. Cependant les autres font:

rails_spawn_method smart;
rails_app_spawner_idle_time 0;
rails_framework_spawner_idle_time 0;
passenger_pool_idle_time 1000;

HTH!

EDIT rails_spawn_methodest obsolète dans le passager 3 à la place

passenger_spawn_method smart;

tout le reste est juste bon jusqu'à ce jour.

— Gav
source
7
Merci pour cela. Une chose à noter est que j'ai dû remplir le fichier passager_pool_idle_time dans mon nginx.conf principal avec les autres paramètres globaux au lieu de simplement dans la configuration de site spécifique où les rails étaient activés.
— Scott Anderson
mais erreur sur le passager 4:"passenger_max_preloader_idle_time" directive is duplicate
— TangMonk
4

Vous pouvez également utiliser PassengerMinInstances:

http://www.modrails.com/documentation/Users%20guide%20Apache.html#PassengerMinInstances

Cela peut être combiné avec PassengerPreStart

— Josh
source
Dans la documentation: "Vous devez définir cette option sur une valeur non nulle si vous souhaitez éviter des temps de démarrage potentiellement longs après qu'un site Web a été inactif pendant une période prolongée." Cela semble être la réponse parfaite à la question du PO.
— Chuck
2

RÉ:

# Additionally keep a copy of the Rails framework in memory. If you're 
# using multiple apps on the same version of Rails, this will speed up
# the creation of new RailsAppSpawners. This isn't necessary if you're
# only running one or 2 applications, or if your applications use
# different versions of Rails.
RailsFrameworkSpawnerIdleTime 0

Juste quelque chose à ajouter et qui pourrait être utile.

La méthode de spawn par défaut dans la version actuelle est "smart-lv2", qui ignore le spawner du framework, donc définir le délai de spawner du framework n'aurait aucun effet de toute façon à moins que vous ne définissiez explicitement la méthode de spawn sur "smart".

Source: http://groups.google.com/group/phusion-passenger/browse_thread/thread/c21b8d17cdb073fd?pli=1

— Shuoling Liu
source
1

Si votre hôte est un serveur partagé, comme le mien, vous ne pouvez pas modifier les paramètres et vous êtes coincé avec une tâche cron.

Pour cette application particulière, heureusement, ce n'est pas le cas. Mais je garderai cela à l'esprit pour l'avenir merci.
— tsdbrown
1

J'ai également eu ce problème mais je n'ai pas pu modifier les paramètres des passagers car je n'avais aucune autorisation en écriture sur ce fichier. J'ai trouvé un outil ( http://www.wekkars.com ) qui permet à mon application de répondre rapidement. Peut-être que cela peut aussi être une solution pour vous.

— SteenhouwerD
source
0

vérifier la version du passager. c'était RailsSpawnMethod <string>pour les anciennes versions.

Si tel est le cas (si je me souviens bien), remplacez Passenger with Rails dans toutes les directives de configuration ou recherchez les anciennes docs des passagers pour plus de détails

— JmJ
source
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.