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

Question

Pour prendre le train en marche de Phusion Passenger, nous avons mis en place un serveur d'essai pour une petite application rails afin de tester les choses.

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

Après avoir parcouru les résultats de Google, nous ne trouvons pas vraiment d'informations utiles. Actuellement, nous avons une tâche cron qui fait une demande tous les deux ans pour essayer de faire fonctionner les serveurs.

Quelqu'un d'autre rencontre-t-il ce problème et avez-vous des conseils pour le résoudre ?

Answer 1

Ce qui se passe, c'est que votre application et/ou vos 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, il existe quelques options de configuration d'Apache que vous pouvez utiliser pour maintenir votre application en vie.

Voici en particulier ce que j'ai fait sur mes serveurs. Les options 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 un mode de création "intelligent" et en désactivant PassengerMaxPreloaderIdleTime, Passenger conservera une copie de votre application en mémoire à tout moment (après la première requête après le démarrage d'Apache). Particulier Application les auditeurs seront fork ée à partir de cette copie, ce qui est une opération très peu coûteuse. Elle se déroule si rapidement qu'il est impossible de savoir si votre application a dû ou non créer un auditeur.

Si votre application est incompatible avec le smart spawning, je recommanderais de garder un grand PassengerPoolIdleTime et de visiter votre site périodiquement en utilisant curl et un cronjob ou monit ou quelque chose comme ça pour s'assurer que l'auditeur reste en vie.

En Guide de l'utilisateur passager est une excellente référence pour ces options de configuration et bien d'autres encore.

éditer : Si votre application est incompatible avec le smart spawning, il y a quelques nouvelles options qui sont très belles

# 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 démarrera 3 instances immédiatement après le chargement d'Apache, et maintiendra toujours au moins 3 instances en service, de sorte que vos utilisateurs ne verront que rarement (voire jamais) un délai.

Ou, si vous utilisez le "smart spawning" (recommandé) avec la fonction PassengerMaxPreloaderIdleTime 0 vous pouvez ajouter PassengerPreStart pour obtenir l'avantage supplémentaire d'un démarrage immédiat.

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

Answer 2

Au cas où des utilisateurs de serveurs nginx tomberaient sur cette question, les directives 'PassengerMaxRequests' et 'PassengerStatThrottleRate' ne se traduisent pas pour nginx. En revanche, les autres le sont :

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

HTH !

EDITAR rails_spawn_method est obsolète dans passenger 3 utilisez plutôt

passenger_spawn_method smart; 

tout le reste est bon jusqu'à présent.

Answer 3

Vous pouvez également utiliser PassengerMinInstances :

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

Elle peut être combinée avec PassengerPreStart

Answer 4

RE :

# 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

Il s'agit simplement d'un élément à ajouter et qui pourrait être utile.

La méthode de spawn par défaut dans la version actuelle est "smart-lv2", qui ne tient pas compte du framework spawner. le timeout du framework spawner n'aurait de toute façon pas d'effet, à moins que vous ne mettiez explicitement la méthode de spawn à "smart".

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

Answer 5

Si votre hébergeur est un serveur partagé, comme le mien, vous ne pouvez pas modifier les paramètres et vous devez vous contenter d'une tâche cron.