Ralentissement du démarrage initial du serveur lors de l'utilisation de Phusion Passenger et Rails
Pour sauter dans le train de Phusion Passenger, nous avons configuré un serveur de transfert pour une petite application Rails pour tester les choses).
Jusqu'à présent, il a été très agréable à utiliser, il facilite l'installation/la configuration et le déploiement d'applications. Le problème est que le site que nous utilisons n'est pas touché très souvent et il semble fermer les serveurs 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, 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 un travail cron qui fait une demande de temps en temps pour essayer de faire fonctionner les serveurs.
Est-ce que quelqu'un d'autre rencontre ce problème et avez-vous des conseils pour une solution?
Ce qui se passe, c'est que votre application et/ou ApplicationSpawners s'arrêtent en raison d'un délai d'attente. 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 en tout temps 1 copie de votre application en mémoire (après la première demande après le démarrage d'Apache). Les auditeurs Application individuels seront forked à partir de cette copie, ce 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.
Si votre application est incompatible avec la génération intelligente, je vous recommande de conserver un grand PassengerPoolIdleTime et de visiter régulièrement votre site en utilisant curl et un cronjob ou monit ou quelque chose pour garantir que l'auditeur reste en vie.
Le Guide de l'utilisateur du passager est une référence géniale pour ces options de configuration et plus encore.
edit : Si votre application est incompatible avec la génération intelligente, il y a de nouvelles options qui sont très gentils
# 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 fera tourner 3 instances immédiatement après le chargement d'Apache, et gardera toujours au moins 3 instances, de sorte que vos utilisateurs verront rarement (voire jamais) un retard.
Ou, si vous utilisez la génération intelligente (recommandée) avec PassengerMaxPreloaderIdleTime 0 déjà, 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 !
Au cas où des utilisateurs du serveur nginx tomberaient sur cette question, les directives 'PassengerMaxRequests' et 'PassengerStatThrottleRate' ne se traduisent pas en nginx. Cependant, les autres:
Rails_spawn_method smart;
Rails_app_spawner_idle_time 0;
Rails_framework_spawner_idle_time 0;
passenger_pool_idle_time 1000;
HTH!
ÉDITER Rails_spawn_method est déconseillé dans le passager 3 à la place
passenger_spawn_method smart;
tout le reste est juste bon jusqu'à la date.
Vous pouvez également utiliser PassengerMinInstances:
http://www.modrails.com/documentation/Users%20guide%20Apache.html#PassengerMinInstances
Ceci 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 à ajouter et qui pourrait être utile.
La méthode d'apparition par défaut dans la version actuelle est "smart-lv2", qui ignore le générateur de framework, donc la définition du délai d'expiration du framework n'aurait aucun effet à moins que vous ne définissiez explicitement la méthode de génération 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 paramètres et vous êtes bloqué avec une tâche cron.
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 d'é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.
vérifier la version du passager. c'était RailsSpawnMethod <string> pour les anciennes versions.
Si c'est le cas (si je me souviens bien), remplacez Passenger par Rails dans toutes les directives de configuration ou recherchez d'anciens documents passager pour plus de détails).