Sortie de Phusion Passenger 2.2.12

Posté par  (site web personnel) . Modéré par patrick_g.
Étiquettes :
13
1
juin
2010
Ruby
Phusion Passenger est un module pour Apache 2 ou Nginx qui permet de déployer simplement des applications Ruby. En particulier, il est très bien adapté aux applications Rails, d'où son surnom de mod_rails. Bien que développé et supporté commercialement par Phusion, l'intégralité du code source est placé sous licence MIT.

La version 2.2.12 est toute fraîche. Elle apporte des corrections de bogues et améliore le support de Bundler, vous permettant ainsi de gérer les dépendances de vos applications et charger les bonnes versions des gems utilisés sur vos projets.

L'installation et la mise à jour peuvent se faire en utilisant le gem passenger, puis en lançant passenger-install-apache2-module ou passenger-install-nginx-module. Brightbox fournit également des paquets pour Ubuntu.

Les développeurs de Passenger recommandent d'utiliser leur version de Ruby. Cette dernière se nomme de façon un peu pompeuse Ruby Entreprise Edition. C'est un Ruby 1.8.7 agrémenté de quelques patches pour améliorer la gestion de la mémoire et le comportement du ramasse-miettes (garbage collector). Ces patches ont été proposés à Matz, mais il les a refusés car ils peuvent dégrader incroyablement les performances dans certains cas en dehors du web.

Aller plus loin

  • # Hébergements Mutualisés

    Posté par  (site web personnel) . Évalué à 2.

    Je me demande si les différents hébergements mutualisés proposant RoR (Maven Hosting, PlanetHoster...) utilisent Phusion Passenger ?
    Dans tous les cas, j'ai entendu dire que les performances pour ce framework étaient très médiocre en mutualisé...
  • # Mouais

    Posté par  (site web personnel) . Évalué à 3.

    Je l'ai utilisé un certain temps avec apache (sous Gentoo, ça joue probablement). Bah c'est pas la joie, avec certaines version ça segfault, avec d'autres c'est juste pas stables, et quand ça marche c'est plus ou moins chiant à configurer.

    Finalement, j'ai tout passé à lighttpd (en fcgi), et c'est génial, ça marche tout le temps, c'est léger, et c'est simple à configurer.

    Bref, c'est bien pour ceux qui sont coincé sur apache.
    • [^] # Re: Mouais

      Posté par  (site web personnel) . Évalué à 1.

      Entendre qu'un gus est passé de Passenger à FastCGI c'est le monde à l'envers.

      Le déploiement d'une application Ruby on Rails en FastCGI n'est quasiment plus recommandée aujourd'hui, quasiment plus personne le fait dans la communauté. C'était une technique utilisée au début du développement de Rails il y a quelques années. Baucoup de problèmes : dur à configurer et débugger, problème de process qui partent en vrille, leaks, performance en req/sec assez basse, etc.

      Aujourd'hui reste 2 solutions fiables et utilisées :
      * Passenger avec Apache ou nginx (hé oui, Passenger peut fonctionner avec autre chose qu'Apache ! nginx est une solution très fiable).

      * Un ensemble de micro-serveurs en Ruby (Thin par exemple) derrière un load-balancer (solution très fiable/scalable, bien que plus lourde à gérer que Passenger).

      Bref, Passenger c'est du très bon car je trouve que l'équipe a très très bien soigné le packaging. L'installation est très claire, on t'indique quels paquets de ta distribution manque, on t'indique la config par défaut à utiliser dans ton vhost, etc. La documentation est aussi très bonne. L'installation de la version optimisée RubyEE est tout aussi bien expliquée et fiable.

      De plus, Passenger est la seule solution envisageable actuellement pour faire du mutualisé RoR. D'ailleurs les hébergeurs américains mutualisés (Dreamhost, etc) l'utilisent.

      Si tu as eu des problèmes c'est sûrement avec une très ancienne version ou bien tu avais un problème dans ta configuration, réessaye :-).
      • [^] # Re: Mouais

        Posté par  . Évalué à 3.

        dur à configurer et débugger, problème de process qui partent en vrille, leaks, performance en req/sec assez basse

        C'est exactement pour ces raisons que j'évite Apache.

        DLFP >> PCInpact > Numerama >> LinuxFr.org

      • [^] # Re: Mouais

        Posté par  . Évalué à 2.

        Vous avez tous les deux raison ;-)

        Passenger est recommandé, mais Passenger dans Gentoo a eu pas mal de problèmes (je n'en connais pas la raison), j'ai dû garder une certaine version de Passenger dans la Gentoo pour que cela fonctionne correctement.
        • [^] # Re: Mouais

          Posté par  (site web personnel) . Évalué à 1.

          Je doit avouer que c'est plus Apache que Passenger que j'ai viré au final :)

          La conf de lighttpd est tellement plus agréable à utiliser ! (Et pourtant de la conf d'apache, j'en ai fait pas mal, ...)
          • [^] # Re: Mouais

            Posté par  . Évalué à 3.

            La conf de nginx est encore meilleure que celle de lighty.
        • [^] # Re: Mouais

          Posté par  . Évalué à 1.

          Il ne doit pas y avoir que sous Gentoo que ça pose des problèmes.

          Je l'ai utilisé il y a quelques-mois, sous Debian mais en prenant la version dans les gems, pas le paquet Debian (version 2.2.9), pour faire tourner un Redmine, qui jusque-là était resté avec le webrick par défaut. Et bien c'est lent. Pour ne pas avoir plusieurs secondes (!) d'attente à chaque accès au site après un certain temps sans s'y connecter, il m'a fallu demander à ce que des instances soient pré-spawnées, mais là c'est la conso en RAM qui douille (je viens de regarder, il prend 180 mégas alors qu'il n'y a pas d'utilisateurs connectés)...

          Et je ne suis pas le seul à avoir ce problème. Après peut-être qu'il y a une config magique qui m'a échappé (pourtant j'ai essayé plusieurs choses), mais en attendant je le tiens pour lent et gourmand.

          C'est vrai par contre qu'il est assez agréable à installer et utiliser.
  • # Passenger sai bien

    Posté par  (site web personnel) . Évalué à 2.

    J'utilise la version 2.2.7 en production. C'est très simple à configurer et pour une charge moyenne (5000 visites jours), ça fait bien son boulot.
    D'une version à l'autre, ils ont tendance à introduire des bugs, il vaut mieux bien tester chaque mise à jour.
    En utilisation avec capistrano, ce n'est que du bonheur.
  • # Ça marche nickel.

    Posté par  . Évalué à 2.

    C'est ce qu'on utilise pour déployer chez FrontFoot (frontfoot.com.au)... et ça marche impeccable. Le portail Planet 3 pour iPhone encaisse environ 2 millions de visiteurs uniques par semaine... et on a une bonne douzaine d'applications Rails qui tournent sur le même serveur... avec moins de visites ceux là, mais malgré tout dans les 100-200 milles visiteurs par semaine pour la plupart.

    On utilise CentOS + Apache + Passenger.
  • # C'est bon pour la flemme, moins pour les perfs

    Posté par  . Évalué à 3.

    Passenger c'est juste pour pour la flemme.

    Configurer par exemple un serveur Unicorn (http://unicorn.bogomips.org/), le faire écouter en socket Unix, ajouter trois lignes dans nginx.conf, ça prends certes un peu plus de temps (y compris le temps de configurer monitd ou god); mais au moins, on a des bonnes perfs après ...

    Avec une 30aine de sites Rails sur une machine de 2Go, sur Passenger c'était la misère totale. Beaucoup trop de RAM utilisée, les sites mettant 3 plombes a se charger, etc.. alors qu'avec Unicorn tout roule niquel.

    En plus cette version n'a pas l'air de corriger le bug saoulant de passenger quand on reloade nginx: passenger pars en vrille, respawn des nouveaux process, croit qu'il est lancé 3 fois sur le même PID, suce toute ta RAM, ton CPU, et te fais des jolis 504 Gateway Time-Out ... \o/ (je viens de reproduire le bug sur la version 2.2.12).

    Bref: passenger c'est bien pour les glandeurs. C'est pour ça que même si j'ai beaucoup de choses a lui reprocher, je l'utilise quand même- pas partout, pas sur des grosses apps, plutôt sur des petits utilitaires a la con où le temps de chargement et l'utilisation CPU/RAM ne me gène pas trop.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.