LinuxFr.

2 views
Skip to first unread message

Jean-François Trân

unread,
Oct 18, 2007, 10:05:18 AM10/18/07
to rails...@googlegroups.com
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...

-- Jean-François.

--
Ruby ( http://www.rubyfrance.org ) on Rails ( http://www.railsfrance.org )

Farzad FARID

unread,
Oct 18, 2007, 10:55:59 AM10/18/07
to rails...@googlegroups.com
Bonjour,

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..
Et peut-être contrebalancer des histoires d'horreur comme celle-ci :  "7 reasons I switched back to PHP after 2 years on Rails" ?

 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

unread,
Oct 18, 2007, 11:16:16 AM10/18/07
to rails...@googlegroups.com
On 10/18/07, Jean-François Trân <jft...@rubyfrance.org> wrote:
>
> 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

unread,
Oct 22, 2007, 5:41:59 AM10/22/07
to rails...@googlegroups.com
> 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.

Frédéric Logier

unread,
Oct 22, 2007, 9:12:46 AM10/22/07
to rails...@googlegroups.com
Le 22/10/07, Fabien Penso a écrit :


En effet c'est inquiétant ... Il y a t-il une alternative viable à part les fastcgi qui ne semble pas mieux ?

Patrick Aljord

unread,
Oct 22, 2007, 9:13:09 AM10/22/07
to rails...@googlegroups.com
On 10/22/07, Fabien Penso <fabie...@gmail.com> 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 :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

unread,
Oct 22, 2007, 9:18:33 AM10/22/07
to rails...@googlegroups.com
On 10/22/07, Fabien Penso <fabie...@gmail.com> 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/

Patrick Aljord

unread,
Oct 22, 2007, 9:18:58 AM10/22/07
to rails...@googlegroups.com
On 10/22/07, Frédéric Logier <fre...@gmail.com> 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.

Frédéric Logier

unread,
Oct 22, 2007, 9:25:00 AM10/22/07
to rails...@googlegroups.com
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.
 En tout cas mongrel leak bien, mais difficile de dire si ça vient de lui ou d'une lib qu'on utilise.

Yann KLIS

unread,
Oct 22, 2007, 9:59:48 AM10/22/07
to rails...@googlegroups.com
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<fre...@gmail.com> a écrit :

Frédéric Logier

unread,
Oct 22, 2007, 10:53:28 AM10/22/07
to rails...@googlegroups.com
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 :)

Jean-François Trân

unread,
Oct 22, 2007, 10:56:51 AM10/22/07
to rails...@googlegroups.com
fredix :

Comme ImageScience ?

http://seattlerb.rubyforge.org/ImageScience.html

Cyril Mougel

unread,
Oct 22, 2007, 11:04:24 AM10/22/07
to rails...@googlegroups.com
On 10/22/07, Jean-François Trân <jft...@rubyfrance.org> wrote:
>
> 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

unread,
Oct 22, 2007, 11:48:48 AM10/22/07
to rails...@googlegroups.com
On 10/22/07, Patrick Aljord <pat...@gmail.com> wrote:

> 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

unread,
Oct 22, 2007, 11:50:07 AM10/22/07
to rails...@googlegroups.com
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...

> 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

unread,
Oct 22, 2007, 11:54:13 AM10/22/07
to rails...@googlegroups.com
On 10/22/07, Eric Daspet <eric....@survol.fr> 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.

Frédéric Logier

unread,
Oct 22, 2007, 12:46:13 PM10/22/07
to rails...@googlegroups.com
Le 22/10/07, Jean-François Trân a écrit :

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

unread,
Oct 22, 2007, 2:31:07 PM10/22/07
to rails...@googlegroups.com
Frédéric Logier a écrit :
> 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

unread,
Oct 22, 2007, 2:44:56 PM10/22/07
to rails...@googlegroups.com
Fabien Penso a écrit :

> 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.

Reply all
Reply to author
Forward
0 new messages