Ebb


#1

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


#2

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 :frowning:

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


Cyril M.
http://blog.shingara.fr


#3

On 9 avr. 2009, at 12:02, Cyril M. removed_email_address@domain.invalid wrote:

C’est plutôt mort :frowning:

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 :slight_smile:


#4

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 :slight_smile:

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 ?


#5

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 :slight_smile:

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


#6

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 :slight_smile:

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 :wink:

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


#7

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


#8

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


#9

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


#10

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.


#11

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)


#12

2009/4/10 Jean-Philippe M. removed_email_address@domain.invalid:

mongrel/thin que passenger.

Et ca reste toujours mieux que du cgi :wink:


http://fabien.jakimowicz.com


#13

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 :


#14

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.


#15

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 :wink:

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.


#16

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 :wink:


#17

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.


#18

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 ?


#19

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”


#20

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 :wink:

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…