Phusion Problèmes de ponte du passager

Question

Je travaille avec une application Rails 3RC et j'utilise Phusion Passenger pour la première fois. Il faut environ 30 secondes pour démarrer l'application sur la première demande et voici la consommation de mémoire typique pour chaque processus rubis dans mon application:

PID         VmSize           privé       Nom
18161 263,5 Mo 75,4 Mo Rack:/rails_apps/mon_app/current

Est-ce typique de la consommation de mémoire? Mon application est d'environ 11 Mo (< 4 Mo si vous n'incluez pas mes/actifs publics).

Il fonctionne bien après la première requête s'il y a un utilisateur, mais je rencontre des problèmes lorsque j'exécute certains scripts de tests de stress personnalisés, et aussi quand j'utilise ma fonction de suggestion de recherche qui fait un tas d'appels ajax rapides (ce à quoi je m'attendais, car la prochaine requête arrive avant que le premier ne se termine). Voici ce que je trouve bizarre .. le serveur commence à engendrer des threads Ruby qui prennent 30 secondes de plus à charger, mais aucune autre requête ne peut passer tant que le frai est en cours. Juste pour vérifier, j'ai testé avec des navigateurs sur d'autres réseaux pendant que les processus naissaient juste pour m'assurer que ce n'était pas quelque chose de spécifique à ma machine locale (comme toutes les demandes traitées par un processus). Ces demandes de navigateur ont dû attendre jusqu'à ce que tous les nouveaux spawns soient terminés.

Donc, ma question est .. est-ce le comportement typique de passager? En attente de frai avant que toute autre demande puisse arriver? En regardant la documentation, je pense que l'autre demande serait traitée par des processus de rubis inactifs pendant que la reproduction se produisait. Voici les versions que j'utilise au cas où vous auriez connaissance d'incompatibilités. Merci d'avance! Je ne veux pas revenir à Mongrel ;-)

ma configuration
Quarter tranche Rackspace Cloud (4 Go de RAM & 1/4 dual core quad)
CentOS 5.4
Rails 3.0RC
rubis 1.9.2dev (2010-05-31 révision 28117) [x86_64-linux]
passagers 2.2.15 avec bâtarde

options de configuration nginx:
passenger_max_pool_size 30;
passenger_enabled on; #in/location block ..

J'ai essayé le frai conservateur et je vois le même comportement.

Answer 1

Le passager 3 est sorti avec une reproduction asynchrone. Vous pouvez même définir un nombre minimum de processus à conserver.

Même avec l'ancien comportement, la plupart des sites à fort trafic ne connaissent pas ce problème parce que:

1. Frai le premier processus est généralement beaucoup plus rapide. Pour moi, les applications Rails prennent généralement 5 secondes pour apparaître.
2. La méthode de ponte intelligente accélère considérablement les processus supplémentaires, ne nécessitant généralement que 10% du temps d'origine.
3. Les personnes ayant des sites Web à forte fréquentation définissent généralement leurs périodes d'inactivité en pool à des valeurs plus élevées, de sorte que les processus ne s'arrêtent pas pendant la journée et se nettoient uniquement pendant la nuit.

Votre consommation de mémoire est un peu élevée. La plupart des applications Rails que j'ai vues nécessitent 20 à 50 Mo de mémoire privée.