Eric D. wrote the following on 13.03.2007 11:55 :
je precise que l’activite du site est proche de l’ancephalogramme plat,
de ram que ça et avec fluidité .Prendre plus que 100Mo de ram pour ça c’est franchement innacceptable.
Comme je le disais, ce n’est pas Rails le plus gourmand dans cette
histoire, mais plutôt MySQL… Sur un mutualisé la base de données et
tout le reste sont déjà présents, tu peux donc compter environ 60M de
RAM.
Evidemment le tableau change lorsqu’on augmente le nombre de Mongrels ou
processus fastcgi…
Pire, pour ne rien gacher notre architecture est fixe : on a lancé 2
mongrels, qui seront toujours là qu’ils reçoivent 0 requêtes ou 50. Ca
aussi c’est innacceptable. Ca fait des années que les serveurs Web savent
gérer un processus léger permanent pour quand il n’y a aucune requête, et
en créer plein à la volée dès qu’il y en a besoin (et les supprimer dès
qu’il y en a trop d’inutilisés).
Rails ne permet pas d’avoir des processus légers et il n’y a pas grand
chose à faire de ce côté (le mieux serait de permettre de forker après
le chargement des librairies et avant l’établissement des connexions
avec la BD, mais c’est complexe et a des effets de bord). De toute
manière ce processus n’est pas intégrable dans le serveur web et
nécessiterait le dev d’un ‘super-mongrel’.
On revient en arrière de presque 12 ans là , tant que le ratio mémoire
utilisée / mémoire dispo que sur la capacité du serveur à s’adapter à sa
charge.Si quelqu’un a une solution je veux bien, mais là on ne s’imposera pas
tant qu’on n’aura pas résolu le(s) problème(s)
Tout dépend du marché que tu adresses. J’ai une appli en production qui
aurait probablement coûté le double si elle avait été faite en PHP (on
passe de plus de 150k€ à 300k€ quand même) et elle tourne dans une
infrastructure qui me coûte moins de 100€ par mois (en comptant la
machine, la bande-passante, la supervision, le backup et une machine de
spare). Pour info, actuellement je m’en sors avec 120M tout compris
alors qu’en plus de lighttpd/rails/PostgreSQL j’ai besoin d’un serveur
Postfix dédié et d’un ordonnanceur en Ruby qui me coûtent 41,5M. En
comptant tout le système, ça fait moins de 80M pour une appli Rails avec
trois processus fastcgi traitant les requêtes HTTP en parallèle.
Je pense pouvoir dire qu’il y a très peu de chances que je dépense ne
serait-ce que 10% des 150k€ de différence en coûts d’hébergement
supplémentaires par rapport à toute autre solution technique…
Il faut positionner Rails face aux infrastructures J2EE qui elles
nécessitent encore plus de RAM (x10 ?) pour le ticket d’entrée, pas en
face de mod_php pour héberger des sites webs vaguement interractifs sur
serveurs mutualisés… Je ne pourrai tout simplement pas héberger une
appli J2EE sur mon infrastructure actuelle, ça me coûterait probablement
3 fois plus cher en hébergement.
Si tu vends Rails en tant que techno pour héberger un site perso chez
Free, il y a erreur de casting.
Lionel
