LinuxFr.
Jean-François Trân
Suite à l'histoire du crash du serveur de LinuxFr,
http://linuxfr.org/2007/10/10/23195.html
un message parlait de :
http://blog.penso.info/2007/09/04/quelques-projets-en-cours
"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 )
Farzad FARID
Jean-François Trân a écrit :
un message parlait de : http://blog.penso.info/2007/09/04/quelques-projets-en-cours "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..
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
Cyril Mougel
>
> Tout le monde a vu ? (bis)
>
> Suite à l'histoire du crash du serveur de LinuxFr,
> http://linuxfr.org/2007/10/10/23195.html
>
> un message parlait de :
> http://blog.penso.info/2007/09/04/quelques-projets-en-cours
>
> "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...
>
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 Mougel
http://blog.shingara.fr
Fabien Penso
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.
Frédéric Logier
En effet c'est inquiétant ... Il y a t-il une alternative viable à part les fastcgi qui ne semble pas mieux ?
Patrick Aljord
> > 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 :D
Sinon pour les fraguements il y a ça aussi:
http://revolutiononrails.blogspot.com/2007/08/fragmentfu-fun-with-fragments.html
ça cause directement avec un handler mongrel sans passer par rails.
Eric Daspet
>
> 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/
Patrick Aljord
>
> 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.
Frédéric Logier
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.
Yann KLIS
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<fre...@gmail.com> a écrit :
Frédéric Logier
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 :)
Jean-François Trân
Cyril Mougel
>
> 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
>
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 :)
Fabien Penso
> bien si tu vois où est le problème vas-y envoie des patch c'est du
> logiciel libre après tout :D
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:
>
> http://revolutiononrails.blogspot.com/2007/08/fragmentfu-fun-with-fragments.html
>
> ça cause directement avec un handler mongrel sans passer par rails.
Ca merite intéret, mais ca regle pas le soucis de cache_pages.
Fabien Penso
> >
> > 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.
Fabien Penso
> > 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.
Frédéric Logier
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
Super, je vais tester, merci.
Bruno Michel
> Le 22/10/07, *Jean-François Trân* a écrit :
> Comme ImageScience ?
>
> http://seattlerb.rubyforge.org/ImageScience.html
>
> Super, je vais tester, merci.
Ou mini-magick : http://rubyforge.org/projects/mini-magick .
Bruno Michel
> On 10/22/07, Frédéric Logier <fre...@gmail.com> wrote:
>> Le 22/10/07, Patrick Aljord 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
http://www.slideshare.net/britt/a-small-talk-on-getting-big-113066 par
exemple). Je ne trouve pas ca très propre, mais ce n'est que mon avis.
Bruno Michel.