Tout le monde a vu ? (bis)
Suite à l’histoire du crash du serveur de LinuxFr,
un message parlait de :
“Réecriture de LinuxFr en Ruby on Rails, avec en tête l’idée de
pouvoir tenir la charge actuelle du site (importante…)”
Si le projet aboutit, ça pourrait marquer les esprits…
– Jean-François.
–
Ruby ( http://www.rubyfrance.org ) on Rails ( http://www.railsfrance.org
)
Bonjour,
Jean-François Trân a écrit :
un message parlait de :
Quelques projets en cours | Random Thoughts“Réecriture de LinuxFr en Ruby on Rails, avec en tête l’idée de
pouvoir tenir la charge actuelle du site (importante…)”Si le projet aboutit, ça pourrait marquer les esprits…
Et peut-être contrebalancer des histoires d’horreur comme celle-ci : “7
reasons I switched back to PHP after 2 years on Rails
http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html”
?
Cordialement,
–
Farzad FARID / Architecte Open Source - Associé
Pragmatic Source / http://www.pragmatic-source.com
Tel : +33 9 53 19 21 90 / Mob : +33 6 03 70 65 46
Rejoignez mon réseau de contacts :
http://www.viadeo.com/invitationpersonnelle/002ic6twokcvmi
On 10/18/07, Jean-François Trân [email protected] wrote:
pouvoir tenir la charge actuelle du site (importante…)"
Si le projet aboutit, ça pourrait marquer les esprits…
C’est sûr que tout gros site internet qui utilise RubyOnRails ne
peuvent qu’aider à son adoption en france. Mais après quand on vot que
Twitter ou Noumba (version FR) sont en Rails. On a déjà des sites à
forte visites en RubyOnRails, et c’est pas spécialement pour ça qu’on
en parle plus en France.
Je pense que la vrai révolution sera quand des Grand compte français
utiliseront RubyOnRails. A quand Rails dans le CAC40.
–
Cyril M.
Le 22/10/07, Fabien P. a écrit :
Si le projet aboutit, ça pourrait marquer les esprits…
Le problème étant que cache_pages fonctionne très mal, est mal
implémentée, et qu’il faudrait en gros en refaire une grosse partie.
Puis mongrel ou fcgid bouffent une quantité de RAM phénoménal. Ca me
donnera l’impression de revenir en 99 à l’époque de mod_perl et de ses
fuites mémoire de l’époque ou il fallait redémarrer Apache tous les
jours (au minimum) pour que les process arretent de bouffer 50m ou
100m chacun.
En effet c’est inquiétant … Il y a t-il une alternative viable à part
les
fastcgi qui ne semble pas mieux ?
On 10/22/07, Fabien P. [email protected] wrote:
Si le projet aboutit, ça pourrait marquer les esprits…
Le problème étant que cache_pages fonctionne très mal, est mal
implémentée, et qu’il faudrait en gros en refaire une grosse partie.
bien si tu vois où est le problème vas-y envoie des patch c’est du
logiciel libre après tout 
Sinon pour les fraguements il y a ça aussi:
ça cause directement avec un handler mongrel sans passer par rails.
On 10/22/07, Fabien P. [email protected] wrote:
Si le projet aboutit, ça pourrait marquer les esprits…
Le problème étant que cache_pages fonctionne très mal, est mal
implémentée, et qu’il faudrait en gros en refaire une grosse partie.
Est-ce que tu as des pointeurs plus précis sur ce qui ne va pas ?
–
Éric Daspet
http://eric.daspet.name/
Si le projet aboutit, ça pourrait marquer les esprits…
Le problème étant que cache_pages fonctionne très mal, est mal
implémentée, et qu’il faudrait en gros en refaire une grosse partie.
Puis mongrel ou fcgid bouffent une quantité de RAM phénoménal. Ca me
donnera l’impression de revenir en 99 à l’époque de mod_perl et de ses
fuites mémoire de l’époque ou il fallait redémarrer Apache tous les
jours (au minimum) pour que les process arretent de bouffer 50m ou
100m chacun.
Le 22/10/07, Patrick A. a écrit :
Cela dit une appli rails qui utilise bien le cache ça va super vite quand
même.
Ca dépend le site. Un site qui possède des sous domaines avec des
layouts et
un contenu différent, il semble difficile d’utiliser un cache global.
En tout cas mongrel leak bien, mais difficile de dire si ça vient de
lui ou
d’une lib qu’on utilise.
On 10/22/07, Frédéric Logier [email protected] wrote:
En effet c’est inquiétant … Il y a t-il une alternative viable à part les
fastcgi qui ne semble pas mieux ?
il y a Merb qui est une version allégée de rails sans actionpack donc
sans fcgi et qui permet de faire des uploads concurrents par exemple
sans bloquer toute ton appli (ce qui est aussi possible avec rails en
utilisant backgrounddrb par exemple). Par contre ça utilise aussi
activerecord et pas mal de rails goodies. DHH a dit cependant qu’en
faisant des tests sur des real life applications (pas des hello
world), rails2 étaient aussi rapide voire plus rapide que merb donc
bon.
Cela dit une appli rails qui utilise bien le cache ça va super vite quand
même.
Le 22/10/07, Yann KLIS a écrit :
Personnellement, je n’ai pas trouvé que Mongrel leakait. Certes, il
consomme bcp, mais je trouve la consommation stable (depuis la version
1.x du moins). Par contre, rmagick est connu pour leaker à mort.
Arg je l’utilise … plus qu’à trouver un remplaçant 
Personnellement, je n’ai pas trouvé que Mongrel leakait. Certes, il
consomme bcp, mais je trouve la consommation stable (depuis la version
1.x du moins). Par contre, rmagick est connu pour leaker à mort.
++
yk
Le 22/10/07, Frédéric Logier[email protected] a écrit :
On 10/22/07, Jean-François Trân [email protected] wrote:
Merci beaucoup pour cette lib Jean-François, je voulais justement
créer une appli de manipulation d’image et je pensais être obligé
d’utiliser Rmagick. Mais avec cette alternative c’est vraiment sympa.
SeattleRB est vraiment une super team 
–
Cyril M.
fredix :
Personnellement, je n’ai pas trouvé que Mongrel leakait. Certes, il
consomme bcp, mais je trouve la consommation stable (depuis la version
1.x du moins). Par contre, rmagick est connu pour leaker à mort.Arg je l’utilise … plus qu’à trouver un remplaçant
Comme ImageScience ?
http://seattlerb.rubyforge.org/ImageScience.html
-- Jean-François.
–
Ruby ( http://www.rubyfrance.org ) on Rails ( http://www.railsfrance.org
)
On 10/22/07, Patrick A. [email protected] wrote:
bien si tu vois où est le problème vas-y envoie des patch c’est du
logiciel libre après tout
Je pense que la core team actuelle s’en fiche. Mais oui j’ai prévue
d’avoir à écrire du code de ce cote la si besoin.
Sinon pour les fraguements il y a ça aussi:
Revolution On Rails: FragmentFu - Fun with Fragments
ça cause directement avec un handler mongrel sans passer par rails.
Ca merite intéret, mais ca regle pas le soucis de cache_pages.
On 10/22/07, Eric D. [email protected] wrote:
Le problème étant que cache_pages fonctionne très mal, est mal
implémentée, et qu’il faudrait en gros en refaire une grosse partie.Est-ce que tu as des pointeurs plus précis sur ce qui ne va pas ?
Non, c’est plutot des experiences perso echangées avec d’autres.
Essayez d’avoir un cache_pages avec globalize…
Autre scenario : une page /article/15-mon-super-titre accede a 20
req/sec. Deja la page sur le fs s’appelera 15.html et n’incluera pas
le titre, donc ca passera par rails tout le temps (meme avec la config
apache qui teste si le .html existe). De plus si la page n’existe pas,
à la première creation, tous les rails genereront la page alors que le
1er process aurait mieux faire de faire un .lock, les autres attendant
que le fichier existe pour le renvoyer. Ca eviterait un DoS.
On 10/22/07, Frédéric Logier [email protected] wrote:
Le 22/10/07, Patrick A. a écrit :
Cela dit une appli rails qui utilise bien le cache ça va super vite quand
même.Ca dépend le site. Un site qui possède des sous domaines avec des layouts et
un contenu différent, il semble difficile d’utiliser un cache global.
Pourquoi ? Suffirait de pouvoir choisir facilement ou il s ecrit, un
sous repertoire par sous domaines et un peu de tuning apache et hop…
En tout cas mongrel leak bien, mais difficile de dire si ça vient de lui ou
d’une lib qu’on utilise.
En général ca vient d’une lib, mais c’est chiant quand meme car c est
un process persistent, même pour un site qui a 2 hits / jour.
Frédéric Logier a écrit :
Le 22/10/07, Jean-François Trân a écrit :
Comme ImageScience ?http://seattlerb.rubyforge.org/ImageScience.htmlSuper, je vais tester, merci.
Ou mini-magick : http://rubyforge.org/projects/mini-magick .
Le 22/10/07, Jean-François Trân a écrit :
Super, je vais tester, merci.
Fabien P. a écrit :
On 10/22/07, Frédéric Logier [email protected] wrote:
Le 22/10/07, Patrick A. a écrit :
Cela dit une appli rails qui utilise bien le cache ça va super vite quand
même.Ca dépend le site. Un site qui possède des sous domaines avec des layouts et
un contenu différent, il semble difficile d’utiliser un cache global.Pourquoi ? Suffirait de pouvoir choisir facilement ou il s ecrit, un
sous repertoire par sous domaines et un peu de tuning apache et hop…
Oui, c’est ce qu’il faudrait faire. Mais en pratique, le cache rails ne
permet pas ca.
En tout cas mongrel leak bien, mais difficile de dire si ça vient de lui ou
d’une lib qu’on utilise.En général ca vient d’une lib, mais c’est chiant quand meme car c est
un process persistent, même pour un site qui a 2 hits / jour.
J’ai déjà vu des présentations ou il était marqué que c’était OK de
relancer mongrel quand il dépasse une certaine taille en mémoire (slide
38 de
A Small Talk on Getting Big par
exemple). Je ne trouve pas ca très propre, mais ce n’est que mon avis.
Bruno M…
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs