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
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.
On 9 avr. 2009, at 12:02, Cyril M. [email protected] 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 
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 ?
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 sentJe 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.
2009/4/10 Renaud (Nel) Morvan [email protected]:
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 sentJe 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
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
2009/4/10 Sébastien Gruhier [email protected]:
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 … ?
2009/4/10 ook? ook! [email protected]:
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 !!!
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.
2009/4/10 Fabien J. [email protected]
2009/4/10 Sébastien Gruhier [email protected]:
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)
2009/4/10 Jean-Philippe M. [email protected]:
mongrel/thin que passenger.
Et ca reste toujours mieux que du cgi
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 [email protected] a
écrit :
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.
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.
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
On 11 avr. 2009, at 11:48, “Renaud (Nel) Morvan”
<[email protected]
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 égalementBon 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.
On 11 avr. 2009, at 17:15, Gregoire LEJEUNE
[email protected] 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 ?
On 11 avr, 11:56, Fernando P. [email protected] 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”
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…