Forum: Rails France Ebb

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Ebb
Emilien T. (Guest)
on 2009-04-09 13:58
(Received via mailing list)
Hello,
Je viens de découvrir le serveur ruby Ebb avec des graphs indiquant
qu'il
dépose Mongrel et Thin...
http://ebb.rubyforge.org/

Vous connaissez, c'est réellement performant ? Et, stable, utilisé en
production ?

a+
Emilien
Cyril M. (Guest)
on 2009-04-09 14:02
(Received via mailing list)
Emilien T. wrote:
> Hello,
> Je viens de découvrir le serveur ruby Ebb avec des graphs indiquant
> qu'il dépose Mongrel et Thin...
> http://ebb.rubyforge.org/
>
> Vous connaissez, c'est réellement performant ? Et, stable, utilisé en
> production ?

C'est plutôt mort :(

seul Jordan bracco a vraiment essayé de l'utiliser. Maintenant il a arrêté.

--
Cyril M.
http://blog.shingara.fr
Fabien J. (Guest)
on 2009-04-09 14:20
(Received via mailing list)
On 9 avr. 2009, at 12:02, Cyril M. <removed_email_address@domain.invalid> wrote:

>
> C'est plutôt mort :(
>
> seul Jordan bracco a vraiment essayé de l'utiliser. Maintenant il a
> arrêté.
>

Thin + asset host sur ip differente + nginx avec gzip le tout en
socket unix tourne plutot bien. Le gain apporté par la socket unix est
la latence mais ca se sent :)
Renaud (Nel) Morvan (Guest)
on 2009-04-10 16:59
(Received via mailing list)
> Thin + asset host sur ip differente + nginx avec gzip le tout en  
> socket unix tourne plutot bien. Le gain apporté par la socket unix est  
> la latence mais ca se sent :)

Je trouve ca assez admirable que des gens se prennent encore la tête à
gérer des clusteurs de thin/ebb/mongrel, à moins d'avoir des projets
qui font la million de hit par jour, du multithread, de l'em, je
n'arrive pas à voir l'intéret par rapport à un mod_rack si ce n'est la
fingerprint. Y a un grand secret que j'ignore ?
Cyril M. (Guest)
on 2009-04-10 17:09
(Received via mailing list)
Renaud (Nel) Morvan wrote:
>> Thin + asset host sur ip differente + nginx avec gzip le tout en
>> socket unix tourne plutot bien. Le gain apporté par la socket unix est
>> la latence mais ca se sent :)
>>
>
> Je trouve ca assez admirable que des gens se prennent encore la tête à
> gérer des clusteurs de thin/ebb/mongrel, à moins d'avoir des projets
> qui font la million de hit par jour, du multithread, de l'em, je
> n'arrive pas à voir l'intéret par rapport à un mod_rack si ce n'est la
> fingerprint. Y a un grand secret que j'ignore ?
Ca permet en priorité de ne pas être dépendant d'Apache.

--
Cyril M.
http://blog.shingara.fr
Fabien J. (Guest)
on 2009-04-10 17:15
(Received via mailing list)
2009/4/10 Renaud (Nel) Morvan <removed_email_address@domain.invalid>:
>
>> Thin + asset host sur ip differente + nginx avec gzip le tout en
>> socket unix tourne plutot bien. Le gain apporté par la socket unix est
>> la latence mais ca se sent :)
>
> Je trouve ca assez admirable que des gens se prennent encore la tête à
> gérer des clusteurs de thin/ebb/mongrel, à moins d'avoir des projets
> qui font la million de hit par jour, du multithread, de l'em, je
> n'arrive pas à voir l'intéret par rapport à un mod_rack si ce n'est la
> fingerprint. Y a un grand secret que j'ignore ?

c'est surement parce que tu aimes tant ta solution que certains en
aiment aussi d'autres ;)

En restant toujours sur la même solution tout en dénigrant les autres,
je doute qu'on ai beaucoup de diversité au final.

J'aime bien la solution passenger, je la conseilles à la majorité de
mes clients qui ont déjà leur infrastructure/admin sys. Je trouve que
c'est une technologie qui peut permettre à rails de mieux s'imposer.
Mais je préfère largement une solution a base de thin/mongrel pour
plusieurs raisons :
 - apache à une latence plus importante que nginx ou lighttpd
 - apache est moins performant que nginx, surtout sur la portion gzip
 - laisser tourner constamment mes applis me permet de voir les fuites
de mémoire sur mes applications et donc de voir les problèmes
 - passenger mets du temps à démarrer la première instance de rails
lors de la première requête, on peut laisser toujours tourner une
appli rails avec passenger, mais on commence à vite perdre l'interet
de passenger
 - la consommation mémoire constante est plus facile à administrer que
des fluctuations en fonction du nombre d'instances lancées

--
http://fabien.jakimowicz.com
Sébastien Gruhier (Guest)
on 2009-04-10 17:21
(Received via mailing list)
Eh alors? etre dependant de thin... c mieux?

Sébastien Gruhier

-----------------------------------------------------------------------
http://xilinus.com       Web Application Development, Consulting,
Training
http://maptimize.com     Markers fusion service for your online maps
Fabien J. (Guest)
on 2009-04-10 17:23
(Received via mailing list)
2009/4/10 Sébastien Gruhier <removed_email_address@domain.invalid>:
> Eh alors? etre dependant de thin... c mieux?

on peut remplacer thin par mongrel ou ebb (si il vivait encore ;)).

on peut remplacer apache par ... ?

--
http://fabien.jakimowicz.com
ook? ook! (Guest)
on 2009-04-10 17:34
(Received via mailing list)
2009/4/10 Fabien J. <removed_email_address@domain.invalid>

>
> 2009/4/10 Sébastien Gruhier <removed_email_address@domain.invalid>:
> > Eh alors? etre dependant de thin... c mieux?
>
> on peut remplacer thin par mongrel ou ebb (si il vivait encore ;)).
>
> on peut remplacer apache par ... ?
>

Tss! De toute façon, moi, je répond à toute mes requêtes HTTP à la main,
na!
(ça prend juste un peu plus de temps, mais je ne dépend que de moi-même)
Fabien J. (Guest)
on 2009-04-10 17:37
(Received via mailing list)
2009/4/10 ook? ook! <removed_email_address@domain.invalid>:
>
> Tss! De toute façon, moi, je répond à toute mes requêtes HTTP à la main, na!
> (ça prend juste un peu plus de temps, mais je ne dépend que de moi-même)
>

voila un homme, un vrai !!!

--
http://fabien.jakimowicz.com
Jean-Philippe M. (Guest)
on 2009-04-10 20:06
(Received via mailing list)
Fabien J. a écrit :
> J'aime bien la solution passenger, je la conseilles à la majorité de
> mes clients qui ont déjà leur infrastructure/admin sys. Je trouve que
> c'est une technologie qui peut permettre à rails de mieux s'imposer.
> Mais je préfère largement une solution a base de thin/mongrel pour
> plusieurs raisons :

Je rajouterais qu'une fois l'infrastructure et la solution de déploiement
en
place, il n'y a pas plus de difficulté à gérer une solution nginx/lighty/etc
+
mongrel/thin que passenger.
Fabien J. (Guest)
on 2009-04-10 20:22
(Received via mailing list)
2009/4/10 Jean-Philippe M. <removed_email_address@domain.invalid>:
> mongrel/thin que passenger.
>

Et ca reste toujours mieux que du cgi ;)

--
http://fabien.jakimowicz.com
Yann KLIS (Guest)
on 2009-04-11 01:06
(Received via mailing list)
En effet, on a mis nginx+thin de côté pour tous nos petits projets
(qui utilisent donc Apache+mod_rails). Mais on garde encore toujours
ce setup pour les gros projets qui ont besoin de "patate".

++

yk

Le 10 avril 2009 14:58, Renaud (Nel) Morvan 
<removed_email_address@domain.invalid> a
écrit :
Renaud (Nel) Morvan (Guest)
on 2009-04-11 13:49
(Received via mailing list)
> > je n'arrive pas à voir l'intéret par rapport à un mod_rack si ce n'est la
> > fingerprint. Y a un grand secret que j'ignore ?
>
> c'est surement parce que tu aimes tant ta solution que certains en
> aiment aussi d'autres ;)
>

Non justement moi je n'ai pas d'amour pour les solutions que je
choisis, je choisis le meilleur rapport finance/performance

> En restant toujours sur la même solution tout en dénigrant les autres,
> je doute qu'on ai beaucoup de diversité au final.

Qui parle de dénigrer, on parle de solution adaptée à la
réalité.
> plusieurs raisons :
>  - apache à une latence plus importante que nginx ou lighttpd
perceptible par un httperf, pas par un humain

>  - apache est moins performant que nginx, surtout sur la portion gzip
perceptible par un httperf, pas par un humain

>  - laisser tourner constamment mes applis me permet de voir les fuites
> de mémoire sur mes applications et donc de voir les problèmes
mouais...

>  - passenger mets du temps à démarrer la première instance de rails
> lors de la première requête, on peut laisser toujours tourner une
> appli rails avec passenger, mais on commence à vite perdre l'interet
> de passenger
super donc ce setup est adapté à des sites qui font 30 req par jours

>  - la consommation mémoire constante est plus facile à administrer que
> des fluctuations en fonction du nombre d'instances lancées
si tu veux, mais passenger peut fonctionner comme ca également

Bon et bien pas de grand secret, juste des critères de goût humain.
C'était bien mon point.
Fernando P. (Guest)
on 2009-04-11 13:56
> Je trouve ca assez admirable que des gens se prennent encore la t�te �
g�rer des clusteurs de thin/ebb/mongrel, � moins d'avoir des projets
> qui font la million de hit par jour, du multithread, de l'em, je
> n'arrive pas � voir l'int�ret par rapport � un mod_rack si ce n'est la
> fingerprint. Y a un grand secret que j'ignore ?
C'est surtout qu'il n'y a aucune prise de tête à monter Nginx+Thin. Je
préfère d'ailleurs 100x lire un fichier de configuration Nginx que celui
d'Apache, et la réactivité d'Igor est fabuleuse, et tout ça avec moins
de ressources consommées.
Fabien J. (Guest)
on 2009-04-11 15:55
(Received via mailing list)
On 11 avr. 2009, at 11:48, "Renaud (Nel) Morvan"
<removed_email_address@domain.invalid
 > wrote:

> choisis, je choisis le meilleur rapport finance/performance
Je reste persuade qu'il faut aussi regarder du cote des solutions qui
nous sont agreables. Sinon pourquoi avoir choisi rails et pas un autre
framework plus rapide ?

>
>> En restant toujours sur la même solution tout en dénigrant les aut
>> res,
>> je doute qu'on ai beaucoup de diversité au final.
>
> Qui parle de dénigrer, on parle de solution adaptée à la réalité.
>
>> plusieurs raisons :
>>  - apache à une latence plus importante que nginx ou lighttpd
> perceptible par un httperf, pas par un humain

Firefox me donne des temps de reponse tres differents sur une machine
evidemment située sur un reseau local. Donc perceptible par un humain.

>
>>  - apache est moins performant que nginx, surtout sur la portion gzip
> perceptible par un httperf, pas par un humain

Meme point ici.

>> de passenger
> super donc ce setup est adapté à des sites qui font 30 req par jours

Point interessant : passenger est toujours moins performant que les
autres solutions evoquées ici. Donc passenger est adapté a ?

>
>>  - la consommation mémoire constante est plus facile à administrer
>>  que
>> des fluctuations en fonction du nombre d'instances lancées
> si tu veux, mais passenger peut fonctionner comme ca également
>
> Bon et bien pas de grand secret, juste des critères de goût humain.
> C'était bien mon point.
>

Au final, tu choisis la solution que tu veux. Si tu souhaites oublier
certains faits ou points constatés pour favoriser tel ou telle
solution, tu ne t'en privera pas. Le choix reste donc humain.

Je constate que des utilisateurs m'ont dis avoir constaté un
changement de vitesse apres la migration de passenger vers nginx/thin.
Ca n'est pas un point verifiable avec un logiciel ou un point de vue
objectif, ca reste purement humain. Et evidemment, ca n'est pas un
site avec 30 req/j.

Mais pourtant ce projet va finir hebergé sur du passenger, pour coller
avec les processus d'hebergement existant de la boite. Je reste sur
mes preferences tout en conseillant d'utiliser des technos auquels on
croit et que l'on maitrise.
Gregoire LEJEUNE (Guest)
on 2009-04-11 19:16
(Received via mailing list)
> Mais pourtant ce projet va finir hebergé sur du passenger, pour coller
> avec les processus d'hebergement existant de la boite. Je reste sur
> mes preferences tout en conseillant d'utiliser des technos auquels on
> croit et que l'on maitrise.

Ouf ! Je vais continuer à utiliser Camping avec un bon vieux
mod_rewrite sur un site (http://phone.vidal.fr) qui fait plusieurs
milliers de requêtes par jour ;)
Renaud (Nel) Morvan (Guest)
on 2009-04-11 19:37
(Received via mailing list)
On 11 avr, 11:56, Fernando P. <removed_email_address@domain.invalid> wrote:
> > Je trouve ca assez admirable que des gens se prennent encore la t te
>
> g rer des clusteurs de thin/ebb/mongrel, moins d'avoir des projets> qui font la million 
de hit par jour, du multithread, de l'em, je
> > n'arrive pas voir l'int ret par rapport un mod_rack si ce n'est la
> > fingerprint. Y a un grand secret que j'ignore ?
>
> C'est surtout qu'il n'y a aucune prise de tête à monter Nginx+Thin. Je
> préfère d'ailleurs 100x lire un fichier de configuration Nginx que celui
> d'Apache, et la réactivité d'Igor est fabuleuse, et tout ça avec moins
> de ressources consommées.

Et le monitoring, le reporting, les packages, trouver un prestataire,
changer de prestataire, la formation, les astreintes, la reprise sur
panne ?

Je fais pas un procès à nginx ou mongrel, c'est du magnique boulot.
Maintenant faut regarder les choses en face et arrêter de conseiller
ce genre de setup en dehors de edge case lié à des charges énormes ou
des environnements fortement mutualisés.

Si on fait un langage comme du ruby c'est sûrement pas pour perdre
tout l'intérêt avec des problèmes d'hébergement d'un autre age. Le
hosting n'est plus l'endroit où chercher la valeur ajoutée alors que
la tendance actuelle avec des chef/puppet c'est qu'il finisse
"commoditized"
Fabien J. (Guest)
on 2009-04-11 19:38
(Received via mailing list)
On 11 avr. 2009, at 17:15, Gregoire LEJEUNE
<removed_email_address@domain.invalid> wrote:

>
C'est une impression ou le nombre de requete que fais ton site te
donne le droit de defendre/attaquer une techno plutot qu'une autre
dans ce thread ?
Gregoire LEJEUNE (Guest)
on 2009-04-11 19:42
(Received via mailing list)
> C'est une impression ou le nombre de requete que fais ton site te
> donne le droit de defendre/attaquer une techno plutot qu'une autre
> dans ce thread ?

Non, par contre ce n'est pas une impression : Les gens sont
susceptibles dès que l'on parle de la techno qu'ils n'utilisent pas ;)

La seule chose que je voulais dire c'est que vive la diversité. C'est
grâce à cela que nous trouverons toujours la meilleure solution au bon
moment...
Renaud (Nel) Morvan (Guest)
on 2009-04-11 19:49
(Received via mailing list)
> >> plusieurs raisons :
> >>  - apache à une latence plus importante que nginx ou lighttpd
> > perceptible par un httperf, pas par un humain
>
> Firefox me donne des temps de reponse tres differents sur une machine  
> evidemment située sur un reseau local. Donc perceptible par un humain.
>

Merge tes js et tes css,compresse les avant gzip,
réduit le nombre d'image et fait du css sprite,
configure tes entêtes expires et fait en sorte que les etags soient
les mêmes sur toutes la machines du clusteur,
utilise des cdn et des dns rapides,
utilise du cache static et fait du reverse proxy,
niveau appli fait du fragment caching

Là tes utilisateurs verront la différence. Mais c'est surement pas la
réactivité de nginx/versus apache qui est un facteur de qualité sur la
vitesse perçue. Faut arrêter de délirer.

Rails 2.3.x a actuellement une performance linérairement décroissante
suivant la taille du html rendu, ce qui veut dire qu'une page html de
500K est 2 fois plus lente qu'une page de 250k simplement à cause de
sa taille parce que la bufferisation effectuée via rack était débile
(en gros on met dans le socket tous les @body.each_line!!!!). Et j'ai
vu personne hurler au loup bien que ca touche tous les types
d'hébergements (ca a quand même été corrigé en douce dans edge). Tout
ca pour dire qu'il y a d'énorme facteur de progression mais qu'ils ne
sont plus dans le choix de tel serveur Vs tel autre. Mais vraiment pas
du tout.
Fabien J. (Guest)
on 2009-04-11 22:06
(Received via mailing list)
On 11 avr. 2009, at 17:48, "Renaud (Nel) Morvan"
<removed_email_address@domain.invalid
 > wrote:

>
> Merge tes js et tes css,compresse les avant gzip,
> réduit le nombre d'image et fait du css sprite,
> configure tes entêtes expires et fait en sorte que les etags soient
> les mêmes sur toutes la machines du clusteur,
> utilise des cdn et des dns rapides,
> utilise du cache static et fait du reverse proxy,
> niveau appli fait du fragment caching

Completement d'accord. Mais je n'ai ni le choix sur le code HTML ni
sur le design et donc les images.

>
> Là tes utilisateurs verront la différence. Mais c'est surement pas
> la
> réactivité de nginx/versus apache qui est un facteur de qualité
> sur la
> vitesse perçue. Faut arrêter de délirer.

Je crois qu'on ne pourra pas tomber d'accord et comme le disais
quelqu'un : la difference nous permet de trouver la bonne solution ou
au moins une solution qui nous convient/plait.

> Tout
> ca pour dire qu'il y a d'énorme facteur de progression mais qu'ils ne
> sont plus dans le choix de tel serveur Vs tel autre. Mais vraiment pas
> du tout.

J'ignorais cette partie sur les changements internes a rails. Merci de
l'info.
Fernando P. (Guest)
on 2009-04-11 23:17
> niveau appli fait du fragment caching
Le fragment caching c'est quand même une plaie douleureuse à maintenir
même si le gain est loin d'être négligeable. Personnellement j'ai
abandonné sauf sur les zones vraiment très simple à sweeper.

Sinon en astuce sympa, il faut tenter de réécrire ses views afin de
basculer en page caching, ça impose quelques concessions niveau design.
C'est facile à maintenir (en tout cas plus que le fragment) et là le
gain est gigantesque. Sur la homepage ou les pages diggables, c'est un
must-have.

> sa taille parce que la bufferisation effectu�e via rack �tait d�bile
> (en gros on met dans le socket tous les @body.each_line!!!!). Et j'ai
> vu personne hurler au loup bien que ca touche tous les types
> d'h�bergements (ca a quand m�me �t� corrig� en douce dans edge).
Intéressant, tu aurais des numéros de commit à indiquer?
Renaud (Nel) Morvan (Guest)
on 2009-04-12 15:44
(Received via mailing list)
On 11 avr, 21:17, Fernando P. <removed_email_address@domain.invalid> wrote:
> > niveau appli fait du fragment caching
>
> Le fragment caching c'est quand même une plaie douleureuse à maintenir
> même si le gain est loin d'être négligeable. Personnellement j'ai
> abandonné sauf sur les zones vraiment très simple à sweeper.

perso c'est clé intelligente + time based expiry, jamais de sweeper

>
> Intéressant, tu aurais des numéros de commit à indiquer?

http://github.com/rails/rails/commit/91d274059536f...

Response#each

Juste:
-        @body.each_line(&callback)
+        callback.call(@body)

Gain de performance sur une page html/xml de 250k *2 sur une page de
500k *4, plutôt que de faire une IO basé sur une taille mémoire fixe
actuellement rack/rails place sur le socket tous les \n, ce qui est
très loin d'être optimal en ruby
Jean-François Trân (Guest)
on 2009-04-13 00:53
(Received via mailing list)
Le 11 avril 2009 17:48, Renaud a écrit :

> vitesse perçue. Faut arrêter de délirer.
Ah ah ah, on sent l'influence koziarskienne sur le Neleanth !

Mais bon, t'as raison. À ce sujet, revoir les slides et la
présentation du nzkoz à Paris on Rails 2008.

http://2008.parisonrails.org/data/pdf/ParisOnRails...
http://2008.parisonrails.org/torrents/ParisOnRails...
http://2008.parisonrails.org/data/video/ParisOnRai...
http://2008.parisonrails.org/torrents/ParisOnRails...
http://2008.parisonrails.org/data/audio/ParisOnRai...

(mp3 58 Mo, quicktime mov 274 Mo, pdf 1,3 Mo)

   -- Jean-François.

--
http://twitter.com/underflow_
Arthur Pétry (Guest)
on 2009-04-17 11:38
(Received via mailing list)
Le 10 avr. 09 à 15:08, Cyril M. a écrit :

>> qui font la million de hit par jour, du multithread, de l'em, je
>> n'arrive pas à voir l'intéret par rapport à un mod_rack si ce n'est
>> la
>> fingerprint. Y a un grand secret que j'ignore ?
> Ca permet en priorité de ne pas être dépendant d'Apache.


Et hop, phusion relance le débat ;-)

  http://blog.phusion.nl/2009/04/16/phusions-one-yea...
  => Phusion Passenger for NginX
This topic is locked and can not be replied to.