[RailsCamp Paris] Ruby on Rails et hébergement mutualisé
Compte-rendu “live” de la session de ce premier Barcamp Paris Rails consacrée à Rails dans les environnements d’hébergement mutualisé que j’ai animé avec Nicolas Mérouze.
Problématiques soulevées :
- Partage des ressources (RAM et processeur) entre les différentes applications.
- Application web nécessitant un redémarrage à chaque changement en mode production, donc des privilèges élevés sur la machine.
- Complexité de mise en place pour un hébergement de masse, aux particuliers.
Problèmes de ressources dans l’hébergement mutualisé
Vu le mode de fonctionnement de Rails, le plus important est de limiter la quantité de mémoire utilisable par une application afin de ne pas gêner les autres. Il faut compter entre 40 et 60 méga octets par processus. Sur un serveur avec 4 giga octets de RAM, en laissant de la place au système, on aura donc un maximum de 75 utilisateurs dans des conditions correctes.
À ce coût, il faut rajouter le ou les serveurs de base de données, les sauvegardes, les temps d’administration… Et on rentre alors dans la boucle coûts / performances / rentabilité / attractivité. Il faut en effet définir un prix rentable pour l’hébergeur et suffisamment attractif pour l’utilisateur. Tout un chantier.
Des différences avec PHP qui rendent les choses plus difficiles à mettre en place
Avec PHP, le serveur web, via mod_php interprète directement les scripts, génère les pages HTML puis les envoie au client.
La majorité des hébergements rails (hors fastcgi) fonctionnent en mode 3 tiers : un serveur d’application va interpréter les scripts ruby avant de les envoyer à un serveur web utilisé en proxy inverse, dont le but est de délivrer les pages HTML et les fichiers statiques (css, images, js…) au client. Les deux solutions logicielles les plus répandues sont :
- Nginx + Thin
- Nginx + Mongrel
- Apache + Mongrel
- Lighttpd + Mongrel
Il existe d’autres solutions basées sur FastCGI, mais ces dernières ne sont pas recommandées dans un environnement de masse / de production en environnement hostile.
Mod_rails, la solution ?
Un nouveau venu qui pourrait bien bien changer la donne a récemment fait son apparition : mod_rails. Ce dernier reconnaît automatiquement les applications Rails dès lors qu’elles ont un /public comme document root. Les processus sont lancés au fur et à mesure des besoins, mais nombre de ressources sont mises en cache, ce qui améliore largement les performances. Enfin, plus besoin de redémarrer les instances à la main, il suffit de mettre un fichier restart.txt dans le répertoire tmp de l’application pour redémarrer cette dernière à l’accès suivant.
Malheureusement, modrails, très jeune, souffre encore de défauts bloquants pour une utilisation en hébergement de masse : peu de possibilités de configuration, et notamment absence de maxexecutiontime et de memorylimit, et surtout pas de support de modalias et modvhost_alias.
À propos
Je m'appelle Frédéric de Villamil, et quand je ne déploie pas ma mauvaise humeur et ma mauvaise foi sur le Web, je suis un super héros chargé de sauver le monde. Vous pouvez me suivre sur Twitter.
À lire également
Si [RailsCamp Paris] Ruby on Rails et hébergement mutualisé vous a intéressé, vous pouvez poursuivre votre lecture avec ces billets similaires :
Soyez le premier à réagir à [RailsCamp Paris] Ruby on Rails et hébergement mutualisé
Trackbacks sur [RailsCamp Paris] Ruby on Rails et hébergement mutualisé
Les trackbacks sont fermés pour cause de spam.
