Lent démarrage du serveur initial lors de l'utilisation des passagers et Rails Phusion

Question

Pour sauter sur la bande-wagon de passagers Phusion nous avons la configuration d'un serveur de mise en scène pour une petite application rails pour tester les choses.

Jusqu'à présent, il a été très agréable à utiliser, il permet d'installer / configurer et déployer un jeu d'enfant apps. Le problème est le site que nous utilisons ne pas être touché très souvent et il semble fermer les serveurs en arrière-plan. Signification quand quelqu'un va sur le site, ils ont une attente très longue jusqu'à ce qu'il démarre un nouveau serveur pour gérer la demande. Nous avons lu dans la documentation, essayé un bon nombre de différents réglages (modes intelligents / smart-LV2, passengeridletime etc.) et ont toujours pas trouvé une vraie solution.

Après le labour à travers les résultats Google nous ne pouvons pas vraiment trouver des informations utiles. À l'heure actuelle, nous avons une tâche cron qui fait une demande chaque-soi-souvent pour tenter de maintenir le fonctionnement des serveurs.

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

Answer 1

Qu'est-ce qui se passe est que votre application et / ou ApplicationSpawners sont en train de fermer en raison de temporisation. Pour traiter votre nouvelle demande, passager doit démarrer une nouvelle copie de votre demande, ce qui peut prendre plusieurs secondes, même sur une machine rapide. Pour résoudre ce problème, il y a quelques options de configuration Apache, vous pouvez utiliser pour garder votre application en vie.

Voici plus précisément ce que je l'ai fait sur mes serveurs. Le 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 reproduction « intelligent » et en éteignant PassengerMaxPreloaderIdleTime, Passager gardera 1 copie de votre demande en mémoire à tout moment (après la première demande après le démarrage d'Apache). les auditeurs individuels Application être de cette édition fork copie, ce qui est une opération super pas cher. Il arrive donc vous pouvez rapidement ne pas dire si oui ou non votre application a dû frayer un auditeur.

Si votre application est incompatible avec la reproduction intelligente, je recommande de garder une grande PassengerPoolIdleTime et frapper votre site périodiquement en utilisant boucle et un cronjob ou Monit ou quelque chose pour assurer l'auditeur reste en vie.

Le passagers Guide de l'utilisateur est une référence impressionnante pour ces derniers et plus d'options de configuration.

modifier : Si votre application est incompatible avec la reproduction intelligente, il y a des 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

Alors, si vous combinez PassengerPreStart et PassengerMinInstances, passager accéléreront à 3 cas immédiatement après charges apache, et toujours garder au moins 3 cas, donc vos utilisateurs rarement (voire jamais) voir un retard.

Ou, si vous utilisez le frai intelligent (recommandé) avec déjà PassengerMaxPreloaderIdleTime 0, vous pouvez ajouter pour obtenir le PassengerPreStart avantage supplémentaire de démarrage immédiat.

Un grand merci aux héros phusion.nl !

Answer 2

Juste au cas il y a des utilisateurs du serveur nginx trébuchant sur cette question, à la fois les « PassengerMaxRequests » et directives « PassengerStatThrottleRate » ne se traduisent pas 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 obsolète passager 3 utiliser à la place

passenger_spawn_method smart; 

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

Answer 3

Vous pouvez également utiliser PassengerMinInstances:

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

Ceci peut être combiné 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

Juste quelque chose à ajouter et pourrait être utile.

La méthode de la rogue de défaut dans la version actuelle est « smart-LV2 », qui ignore le géniteur-cadre, donc la mise en le délai d'attente génitrice-cadre aurait pas d'effet de toute façon, à moins que vous explicitement définir la méthode de spawn à « intelligent ».

Source: http://groups.google.com/group/ Phusion passager / browse_thread / fil / c21b8d17cdb073fd? PLI = 1

Answer 5

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

Answer 6

J'ai aussi eu ce problème, mais je n'a pas pu modifier les paramètres de passagers parce que je n'avais pas l'autorisation d'écrire dans ce fichier. J'ai trouvé un outil ( http://www.wekkars.com ) qui maintient mon application répondre rapidement. Peut-être que cela peut aussi être une solution pour vous.

Answer 7

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

Si oui (si je me souviens bien), remplacer passager avec Rails dans toutes les directives de configuration ou rechercher des anciens documents de passagers pour plus de détails