Le Mar 13 mars 2007 14:43, Frédéric Logier a écrit :
Je ne comprend pas pourquoi tu tiens à comparer PHP et Rails. Compare Ruby
et PHP, et là l’avantage de Ruby est plutôt faible. Idem pour Java, on ne
développe pas un site en Java mais on utilise un framework type Struts.
Les problèmatiques des framework n’ont rien à voir avec celles d’un simple
langage inclus dans Apache via un mod_tonlangage.
Je compare une “solution”. Je ne parle pas de framework pour PHP parce
qu’ils n’imposent rien sur l’hébergement (contrairement à Rails). Je ne
voyais pas le but d’en nommer un parce qu’ils sont tous équivalents sur ce
point. Tu peux prendre Symfony si tu veux un exemple.
Le fait est qu’installer un applicatif J2EE ou PHP est bien plus simple
qu’un applicatif Rails.
le mieux en attendant une amélioration ne serait-il pas de sous-traiter
cela à des spécialistes du genre Typhon ou Telecom Italia ?
Si, mais c’est bien uniquement ce qui motive mon constat : on a un
problème de ce côté là pour l’instant. Je n’ai rien dit de plus.
–
Éric Daspet
http://eric.daspet.name/
Le 13/03/07, Eric D. a écrit :
Ok sans doute pour des entreprises souhaitant une solution clic and
play.
Mais pour une entreprise ayant fait réellement le choix de Rails prête Ã
s’investir un minimum car elle voit très bien les avantages que Rails
lui
apporte, je n’y vois aucun problème.
Les problèmes que tu cites concernent plus les hébergements mutualisés
en
Rails, donc par définition destinés à un public non professionnel. En
effet
sur ce type de profil Rails n’est sans doute pas adapté …
Le 13/03/07, Lionel B. a écrit :
Frédéric Logier wrote the following on 13.03.2007 14:48 :
D’après le chan irc #postgresqlfr l’autovaccum n’est plus dans un
process séparé depuis la 8.1 mais dans le moteur.
Ils se trompent. Cf doc postgreSQL.
Alors ce démon ne se lance que lorsque PostgreSQL le juge nécessaire
d’une
part, c’est un process controllé par PostgreSQL. D’autre part, il faut
également activer l’option stats_start_collector. CF la doc … 
Le Mar 13 mars 2007 14:58, Lionel B. a écrit :
Le problème n’est pas Rails alors, mais le serveur web.
Nous sommes d’accord. Je ne cherchais pas “à qui la faute”. Disons que
j’ai un problème “avec Rails”, pas forcément à cause de lui.
Si c’est pour un serveur dédié, je ne vois pas l’intérêt de forker à
la demande, ton serveur a une capacité, la dépasser ne sert à rien et ne
pas pré-lancer un mongrel te coûtera au moment où tu en auras besoin
Ah si. Si c’est une application de moyenne importance on va tenter de
mettre deux applications sur le même serveur, donc espérer que l’une
pourra prendre plus quand l’autre est en sommeil, ou, ce qui se fait
énormément en entreprise, faire tourner le serveur sur une machine
virtuelle (donc espérer qu’elle prendra le moins de ressources possible
même si elle a l’impression d’être seule).
Je parle surtout PHP en tant que Personal Home Page sur serveurs
mutualisés. Après il y a effectivement la catégorie des applications
pro en PHP
Je ne fais pas la différence. Pour moi cette différence est
majoritairement un fort égo des architectes professionnels. En pratique
j’ai presque l’impression d’avoir vu les applis les plus pro et complètes
dans le milieu privé plutot que le milieu entreprise.
Ce qui est fait en entreprise est le plus souvent tout aussi simple que
ce
qui est fait en privé, et Rails vise largement cette cible.
Ce qui est fait par 43things ou par nouvelobs / figaro madamme, pour
prendre des référence connues, ce n’est pas du développement en soi
trèscomplexe. Pas tellement plus complexe qu’un moteur de blog complet ou
qu’un forum bien fait.
–
Eric D.
http://eric.daspet.name/
Le 13 mars 07 à 12:49, Lionel B. a écrit :
Si tu vends Rails en tant que techno pour héberger un site perso chez
Free, il y a erreur de casting.
C’est clair que comparer une techno comme php à un serveur
d’application comme rails n’est pas du tout avisé. C’est comme
comparer un stockage fichier et un serveur de base de donnée.
Ca ne sera jamais une techno aussi simple et low cost que php parce
qu’il faudra toujours un process persistant et que donc on ne pourra
jamais empiler les sites sur un même serveur comme on le fait avec php.
Néanmoins il y a quand même un défaut majeur avec rails (ruby…)
c’est son incapacité à gérer le multithread et tant que ce sera le
cas et qu’en attendant il n’y a aura pas de vraie solution pour gérer
le nombre de process actif en fonction de la charge et bien la
situaton ne changera pas.
Maintenant Lionel a raison il faut savoir remettre les choses dans
leur contexte. Rails scale très bien en terme technique et financier.
Dans un contexte professionnel l’hébergement Rails peut être
considéré comme peu onéreux. C’est uniquement au niveau du grand
publique que ca pose problème, pas plus qu’avec Java il n’y aura
jamais d’hébergement rails quasi gratos comme il y a pu en avoir avec
php (et qui a tendance à disparaitre à cause des cms mamouthesques
qui sont maintenant la norme).
Renaud_______________________________________________
Railsfrance mailing list
[email protected]
http://lists.rubyonrails.fr/mailman/listinfo/railsfrance
Le 13 mars 07 à 11:54, Jérémy Dierx a écrit :
Bonjour,
A titre de comparaison, voici ma config sur dédié :
mysql 11413 0.0 1.8 78468 18976 ? S Mar07 0:02 /usr/
sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql –
pid-file=/var/run/mysqld/mysqld.pid --skip
11 process mysql
root 25394 0.0 3.0 32536 30860 ? S Mar08 0:19 /usr/
local/bin/ruby /usr/local/bin/mongrel_rails start -d -e production -
p 8002 -a 127.0.0.1 -P log/mongrel.8002.p
root 12832 0.0 3.0 32504 30876 ? S Mar08 0:18 /usr/
local/bin/ruby /usr/local/bin/mongrel_rails start -d -e production -
p 8003 -a 127.0.0.1 -P log/mongrel.8003.p
2 mongrels
/usr/sbin/mysql mysql 20526 0.0 13.0 94036 28944 ?
11 process mysql
/usr/bin/ruby18root 11378 0.0 14.4 36040 32020 ? S Mar12 0:06
2 process mongrels
Petite remarque sur ces deux configs
- vous avez 5 fois plus de daemon mysql qui attendent que de process
mongrel qui déserve, c’est comme d’avoir 2 avions de lignes et 11
pistes d’atterissage, du pure gachi surtout sur une config avec 256
Meg de ram
Rails est un serveur d’application non multithread, chaque process a
sa propre connexion qu’il fait persister et l’utilise de facon
synchrone donc rails n’en utilise jamais plus que 2 à la fois !!
- Mongrel a l’air de tourner en root et c’est franchement pas du
tout une bonne
idée
11 process mysql
si tu sais ou on peut regler ça, je suis preneur…
- Mongrel a l’air de tourner en root et c’est franchement pas du tout
une bonne idée
oui, c’est vrai. c’est du temporaire, mais en effet, c’est pas bien ©
gUI
–
Guillaume B. : (05 61) 19 40 65 / bureau 602N
Les problèmes que tu cites concernent plus les hébergements mutualisés
en Rails, donc par définition destinés à un public non professionnel. En
effet sur ce type de profil Rails n’est sans doute pas adapté …
J’ai un peu le même sentiment qu’E. Daspet à propos de Rails, ou plus
exactement les solutions d’hébergement, ce qui est intimement lié. Rails
est quand même “vendu” comme un “php killer” par DHH à travers ses
screencasts. Et je ne trouve pas déplacé de comparer Rails à php dans la
mesure ou ce dernier ne permet (quasiment) que du développement web,
même si techniquement il faut le comparer à des frameworks comme
symphony.
L’essentiel des entreprises sont des PME avec des besoins assez limités,
les projets à 150000€ ne sont pas majoritaires, il y a donc à mon avis
un réel besoin pour des projets plus modestes bénéficiant tout de même
des avantages d’un développement ruby/rails (mvc, syntaxe agréable,
tests…)
Le 15 mars 07 à 12:55, Guillaume Zifro DESRAT a écrit :
est justement prévu pour Ruby 2.0 d’utiliser des threads POSIX.
Courage, encore un an ou deux !
Je n’ai pas dis le contraire, à ma connaissance le problème actuel se
situe à 2 niveaux:
-L’implémentation actuelle de rails ne supporte le multithread que
sur une petite partie du code (les scopes par exemple). C’est un
nasty little secret et aucune action pour remédier à cela n’est
planifié pour l’instant. (+ d’info sur http://rubyforge.org/pipermail/
mongrel-users/2006-May/000302.html ) Une des raisons du faible
intéret du core pour cela est sans doute lié au faible gain en
perspective (cf la suite).
-L’implémentation actuelle des thread dans ruby est pas mal décriée.
Pas mal de projet sérieux qui gère la concurrence commence par
utiliser les thread ruby et finisse par passer à une autre solution,
mongrel qui implémente maintenant son propre système de thread,
backgroundrb qui est passé en multiprocess… Je n’ai jamais
expérimenté ni rien lu à ce propos de très concret sur le pourquoi du
comment, si ce n’est qu’effectivement pour maximiser la compatibilité
cross plateform ruby n’a pas utilisé de thread natif mais implémente
sa propre solution logicielle. J’imagine qu’une partie du problème
est donc lié à une performance déplorable de l’implémentation des
threads actuels qui de ce fait n’aurait aucun intéret pour rails mais
là je spécule. Si tu as plus d’information je suis preneur, c’est
vraiment une question qui m’intrigue et plutôt inquiétante.
Renaud_______________________________________________
Railsfrance mailing list
[email protected]
http://lists.rubyonrails.fr/mailman/listinfo/railsfrance
Le mardi 13 mars 2007 à 15:34 +0100, Renaud Morvan a écrit :
2) Mongrel a l’air de tourner en root et c’est franchement pas du
tout une bonne idée
Merci pour le conseil j’ai maintenant changé le user des process
mongrel à mon user personnel.
Pour éviter à d’autre de chercher comment faire, dans le fichier de
config mon_appli.yml spécifique à l’appli et déstiné à mongrel, il faut
ajouter :
user: mon_user
group: mon_group
- vous avez 5 fois plus de daemon mysql qui attendent que de process
mongrel qui déserve, c’est comme d’avoir 2 avions de lignes et 11
pistes d’atterissage, du pure gachi surtout sur une config avec 256
Meg de ram
Là , je comprends pas trop, je n’ai pas configuré mysql_multi, j’ai
simplement installé mysql par les paquets dispo… et je me retrouve
avec plein de petits gremlins mysqld 
Si quelqu’un peut m’expliquer ? Et me dire comment en arrêter quelques
uns ?
Jérémy.
On 3/13/07, Frédéric Logier [email protected] wrote:
Heu perso j’utilise en production une dédibox à 30€ HT/mois … Maximum 100€
/mois chez OVH.
C’est un peu le danger des perfectionnistes qui sont souvent mal compris, et
les gens comprennent : Rails c’est bien pour des projets à partir de 150K€
… 
Je ne pense pas que rails ce soit bien uniquement pour les projets Ã
partir de 150K€.
Exemple: une application de gestion de stock/facturation/sav/prises de
commandes/ventes/achats/avoirs en rails utilisée en interne uniquement
par une PME donc pas plus d’une centaine d’utilisateurs par jours.
Dans ce cas, un serveur Kimsufi suffit largement (sans mauvais jeux de
mots), on peut même faire tourner l’application sur un serveur en
interne. Hors une petite application comme celle-là ne vaut même pas
10k€ (j’en ai fait une en une semaine et je suis sur qu’on peut
faire beaucoup mieux :D)
Rails c’est fait pour faire des applications en réseaux, pas forcément
des sites web2.0, et là c’est super rentable parceque l’application tu
la développes de manière super rapide et pour un coup minimum niveau
hardware (n’importe quel serveur suffit) comme software (rails, apache
mongrel etc c’est gratuit).
Après c’est sûr que si tu veux faire un site web qui accueillera des
millions de visiteurs là il faut prévoir une architecture hardware
béton mais ce se sera pareil pour du php et du java.
Et en ce qui concerne du mutualisé gratuit ou quasi-gratuit, ça existe
déjà !
http://www.hostingrails.com/
http://www.soyhost.com/
et pour ceux qui ont des problèmes de RAM et MySQL, n’oubliez pas de
chacher à fond tous que vous pouvez 
Pour finir, c’est vrai que Ruby ne gère pas les thread (pour
l’instant), mais avec mongrel il y a le plugin fastthread qui résoud
pas mal le problème.
On 15 mars 07, at 17:09, Renaud Morvan wrote:
Ca marche avec ruby, ca implémente des threads pour ruby
Absolument pas. fastthread accélère l’exécution des green-threads
ruby, il ne les remplace pas. Il ne fait “que” remplacer les
implémentations des classes Mutex, ConditionVariable, Queue et
SizedQueue par des version plus rapides et fixe au passage de gros
leaks.
ce n’est pas codé avec ruby, c’est bien un workaround
Ce n’est pas un workaround, c’est un fix.
–
Luc H.
Le 13/03/07, Zambra a écrit :
L’essentiel des entreprises sont des PME avec des besoins assez limités,
les projets à 150000€ ne sont pas majoritaires, il y a donc à mon avis
un réel besoin pour des projets plus modestes bénéficiant tout de même
des avantages d’un développement ruby/rails (mvc, syntaxe agréable,
tests…)
Heu perso j’utilise en production une dédibox à 30€ HT/mois … Maximum
100€
/mois chez OVH.
C’est un peu le danger des perfectionnistes qui sont souvent mal
compris, et
les gens comprennent : Rails c’est bien pour des projets à partir de
150K€
…
Par contre il faut quelqu’un qui sache administrer un serveur Linux et
la
config Rails. Mais le problème est le même pour une entreprise qui
décide de
gérer elle-même ses serveurs.
Ce que veux dire Eric c’est qu’il n’est pas aisé, pour une entreprise
qui
souhaite proposer de l’hébergement mutualisé, d’optimiser au mieux ses
ressources matériels.
Cependant un prestataire spécialisé pourra sans problème effectuer ce
travail sur un serveur dédié, ou simplement un salarié administrateur
Linux.
Le 13/03/07, Renaud Morvan[email protected] a écrit :
Néanmoins il y a quand même un défaut majeur avec rails (ruby…)
c’est son incapacité à gérer le multithread et tant que ce sera le
cas et qu’en attendant il n’y a aura pas de vraie solution pour gérer
le nombre de process actif en fonction de la charge et bien la
situaton ne changera pas.
Ruby gère le multithread, actuellement en interne (dans
l’interpréteur), mais je crois pouvoir affirmer sans me tromper qu’il
est justement prévu pour Ruby 2.0 d’utiliser des threads POSIX.
Courage, encore un an ou deux !
–
Guillaume “Zifro” DESRAT
Secrétaire de l’association Ruby France
http://www.rubyfrance.org/
Le 15 mars 07 à 16:25, Jean-François Trân a écrit :
ActiveRecord est sensé être thread safe. Merb qui est multithreadé,
peut utiliser AR.
J’ai eu personnellement avec AR les mêmes problèmes que zed souligne
en ce qui concerne les connexions sql qui ne sont pas fermé et ne
passe pas dans le GC. Ce qui est particulièrement énervant puisque un
daemon comme mysql n’autorise plus les connexions une fois qu’on a
dépassé le maximum. http://rubyforge.org/pipermail/backgroundrb-devel/
2006-October/000445.html
Donc ca reste assez relatif. Mais je suis d’accord avec toi AR est ce
qui me semble le plus multithreadé dans rails, c’est également celui
qui est le plus difficile à rendre vraiment multithread. Maintenant
si tu commences à faire des trucs un peu amusant comme de redéfinir
des réflexions à la volée tu vas avoir de mauvaise surprise car tout
est stockée sous forme de variable de classe.
mais celle-ci n’est pas spécifique à Mongrel.
Fastthread n’est pas spécifique à mongrel mais surtout n’est pas codé
en ruby, c’est du compilé. Ca marche avec ruby, ca implémente des
threads pour ruby, ce n’est pas codé avec ruby, c’est bien un
workaround
De plus, fastthread
a été mergé dans la branche 1.8 ; ainsi par exemple, il est utilisé
par défaut dans 1.8.6, on peut désactiver ce comportement dans
une option de configure.
Alors ca c’est super, je ne le savais pas. Content que ca avance dans
le bon sens même avant la 2.0. On aura peut-être pas besoin
d’attendre deux ans alors, en attendant retour à la réalité et à la
gestion manuelle de process mongrel, ou à fcgi :).
Le 15/03/07, Renaud Morvan a écrit :
Pas mal de projet sérieux qui gère la concurrence commence par
utiliser les thread ruby et finisse par passer à une autre solution,
Tout le monde sait qu’un projet sérieux qui souhaite être hautement
concurrent utilise Erlang 
Sinon il me semble avoir lu que les threads systèmes sont prévu pour
Ruby2.
A voir du côté de la version dev 1.9
Renaud :
quelques remarques…
Je n’ai pas dis le contraire, à ma connaissance le problème actuel
se situe à 2 niveaux:
-L’implémentation actuelle de rails ne supporte le multithread que
sur une petite partie du code (les scopes par exemple).
ActiveRecord est sensé être thread safe. Merb qui est
multithreadé,peut utiliser AR.
C’est un nasty little secret et aucune action pour remédier à cela n’est
planifié pour l’instant. (+ d’info sur http://rubyforge.org/pipermail/
mongrel-users/2006-May/000302.html ) Une des raisons du faible
intéret du core pour cela est sans doute lié au faible gain en
perspective (cf la suite).
-L’implémentation actuelle des thread dans ruby est pas mal
décriée. Pas mal de projet sérieux qui gère la concurrence commence
par utiliser les thread ruby et finisse par passer à une autre solution,
mongrel qui implémente maintenant son propre système de thread,
Ah bon ?
Zed S. encourage l’utilisation de la lib fastthread de MenTalguY,
mais celle-ci n’est pas spécifique à Mongrel. De plus, fastthread
a été mergé dans la branche 1.8 ; ainsi par exemple, il est utilisé
par défaut dans 1.8.6, on peut désactiver ce comportement dans
une option de configure.
backgroundrb qui est passé en multiprocess… Je n’ai jamais
expérimenté ni rien lu à ce propos de très concret sur le pourquoi
du comment, si ce n’est qu’effectivement pour maximiser la
compatibilité cross plateform ruby n’a pas utilisé de thread natif
mais implémente sa propre solution logicielle.
Sans rentrer dans le débat threads natifs vs. green threads,
je rappellerai qu’au départ (les spécialistes Java me corrigeront),
Java implémentait son système de green threads.
A ce propos, JRuby utilise les threads Java et non les threads
Ruby.
– Jean-François.