Démarrage lent du serveur lors de l’utilisation de Phusion Passenger and Rails

Pour sauter sur le podium de Phusion Passenger, nous avons mis en place un serveur de staging pour une petite application de rails afin de tester les choses.

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

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

Quelqu’un d’autre connaît-il ce problème et avez-vous des conseils pour y remédier?

Ce qui se passe, c’est que votre application et / ou ApplicationSpawners s’arrêtent en raison d’un dépassement de délai. 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 ce problème, vous pouvez utiliser quelques options de configuration Apache pour que votre application rest active.

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 de génération “intelligent” et en désactivant PassengerMaxPreloaderIdleTime, Passenger conservera 1 copie de votre application en mémoire à tout moment (après la première demande après le démarrage d’Apache). Les écouteurs individuels de l’ Application seront issus de cette copie, ce qui est une opération très bon marché. Cela arrive si vite que vous ne pouvez pas dire si votre application a dû engendrer un auditeur.

Si votre application est incompatible avec Smart Spawning, je vous recommande de conserver un grand PassengerPoolIdleTime et de bash régulièrement votre site en utilisant curl et un cronjob ou un monit ou quelque chose pour assurer que l’écouteur rest en vie.

Le Guide de l’utilisateur du passager est une référence impressionnante pour ces options de configuration et d’autres.

edit : Si votre application est incompatible avec la génération intelligente, il y a 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 

Donc, si vous combinez PassengerPreStart et PassengerMinInstances, Passenger montera 3 instances immédiatement après les chargements Apache et conservera toujours au moins 3 instances, de sorte que vos utilisateurs ne verront que rarement (voire jamais) un délai.

Ou, si vous utilisez Smart Spawning (recommandé) avec PassengerMaxPreloaderIdleTime 0 déjà, vous pouvez append PassengerPreStart pour obtenir l’avantage supplémentaire du démarrage immédiat.

Merci beaucoup aux héros de phusion.nl !

Juste au cas où des utilisateurs du serveur nginx trébucheraient sur cette question, les directives «PassengerMaxRequests» et «PassengerStatThrottleRate» ne sont pas traduites 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_method est déconseillé chez passager 3 à la place

 passenger_spawn_method smart; 

tout le rest est juste bon jusqu’à la date.

Vous pouvez également utiliser PassengerMinInstances:

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

Cela peut être combiné avec PassengerPreStart

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 à append et pourrait être utile.

La méthode par défaut de spawn dans la version actuelle est “smart-lv2”, qui ignore le spawner du framework, de sorte que définir le délai d’expiration du framework n’a aucun effet à moins de définir explicitement la méthode spawn sur “smart”.

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

Si votre hôte est un serveur partagé, comme le mien, vous ne pouvez pas modifier les parameters et vous êtes coincé avec un travail cron.

J’ai également eu ce problème mais je n’ai pas pu modifier les parameters du passager car je n’avais pas de permission en écriture pour 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.

vérifier la version du passager. c’était RailsSpawnMethod pour les anciennes versions.

Si c’est le cas (si ma mémoire est bonne), remplacez Passenger with Rails dans toutes les directives de configuration ou recherchez d’anciens documents passagers pour plus de détails.