Qui dit asynchrone dit timeout, je ne sais s'il est tout simplement possible de demander a ror d'effectuer une requète HTTP et de sortir en timeout si en 400 ms aucune réponse n'ai arrivée. De même pour une simple requète DNS.
Bien qu'il faille chercher assez loin pour trouver la réponse, oui, Ruby permet de faire cela, et RoR utilise ces capacités, pour ActiveResource par exemple.
Est-ce que ruby sait tirer profit des processeurs multicore ?
Oui, il suffit de lancer plusieurs processus.
Est-ce que son modèle de threads ne passe pas sont temps à mettre des lock empéchant tout simplement toute notion de parallèlisation ?
La question est biaisée. Oui, le modèle de threads de Ruby est catastrophique, mais rien n'empêche de paralléliser avec des processus.
Un langage adapté, et ce n'est pas le cas de ruby.
En l'absence d'arguments, c'est du FUD.
Documente toi sur le modèle Acteur, regarde Scala, Erlang, Haskell, essaie de comprendre la raison d'être de ses langages, tu verras que ruby n'est rien d'autre qu'un n ieme langage sans réel intérêt...
Je me suis documenté sur tout cela. Ruby n'est probablement pas le langage le plus adapté pour la haute disponibilité, mais Ruby présente un réel intérêt à mes yeux. Pour développer des frontaux web, Ruby (ou Python) reste à mes yeux largement préférable aux langages que tu as cité. D'ailleurs, est-tu seulement capables de me donner le nom d'un seul site web à fort trafic qui utilise Scala ou Haskell ? Pour Erlang, c'est facile, Twitter a déjà été cité (et visiblement utiliser erlang n'a pas suffit à résoudre leurs problèmes de montée en charge).
Relis tout ce qu'à ecrit Zen Shaw, auteur de mongrel, et ce qu'il pense de la communauté ruby...
Zen Shaw est connu pour être un personnage avec un certain tempérament. Bien que très justes sur le point technique, ses écrits mettent surtout en avant ses relations tendues avec certaines personnes influentes de la communauté Ruby. Il n'y a pas de remise en cause de Ruby.
Bref creuse le sujet de la scalabilité, car tu fais fausse route...
Des sites à fort trafic s'en sortent très bien avec RoR. Je ne pourrais pas en dire autant d'autres langages. Haskell est par exemple connu pour avoir des performances très difficiles à prédire, ce qui est, à mon avis, un point bloquant pour assurer des montées en charge dans de bonnes conditions.
Pour finir, je te ferais remarquer que tu as tendance à mélanger haute disponibilité et scalabilité. Bien que ces deux notions soient souvent liées, elles ne se recouvrent pas totalement. En particulier, pour la scalabilité, respecter certains grands principes est souvent moins important que l'expérience empirique. L'exemple typique est l'utilisation d'un cache : on cache telles ou telles données en testant et en regardant ce qui marche le mieux. Cela aide grandement à la montée en charge à un point tel que le site ne peut plus fonctionner sans un cache "chaud", ce qui est loin d'être idéal pour la haute disponibilité.
[^] # Re: Et du côté des perfs ?
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Ruby on Rails 2.1 disponible. Évalué à 5.
Bien qu'il faille chercher assez loin pour trouver la réponse, oui, Ruby permet de faire cela, et RoR utilise ces capacités, pour ActiveResource par exemple.
Est-ce que ruby sait tirer profit des processeurs multicore ?
Oui, il suffit de lancer plusieurs processus.
Est-ce que son modèle de threads ne passe pas sont temps à mettre des lock empéchant tout simplement toute notion de parallèlisation ?
La question est biaisée. Oui, le modèle de threads de Ruby est catastrophique, mais rien n'empêche de paralléliser avec des processus.
Un langage adapté, et ce n'est pas le cas de ruby.
En l'absence d'arguments, c'est du FUD.
Documente toi sur le modèle Acteur, regarde Scala, Erlang, Haskell, essaie de comprendre la raison d'être de ses langages, tu verras que ruby n'est rien d'autre qu'un n ieme langage sans réel intérêt...
Je me suis documenté sur tout cela. Ruby n'est probablement pas le langage le plus adapté pour la haute disponibilité, mais Ruby présente un réel intérêt à mes yeux. Pour développer des frontaux web, Ruby (ou Python) reste à mes yeux largement préférable aux langages que tu as cité. D'ailleurs, est-tu seulement capables de me donner le nom d'un seul site web à fort trafic qui utilise Scala ou Haskell ? Pour Erlang, c'est facile, Twitter a déjà été cité (et visiblement utiliser erlang n'a pas suffit à résoudre leurs problèmes de montée en charge).
Relis tout ce qu'à ecrit Zen Shaw, auteur de mongrel, et ce qu'il pense de la communauté ruby...
Zen Shaw est connu pour être un personnage avec un certain tempérament. Bien que très justes sur le point technique, ses écrits mettent surtout en avant ses relations tendues avec certaines personnes influentes de la communauté Ruby. Il n'y a pas de remise en cause de Ruby.
Bref creuse le sujet de la scalabilité, car tu fais fausse route...
Des sites à fort trafic s'en sortent très bien avec RoR. Je ne pourrais pas en dire autant d'autres langages. Haskell est par exemple connu pour avoir des performances très difficiles à prédire, ce qui est, à mon avis, un point bloquant pour assurer des montées en charge dans de bonnes conditions.
Pour finir, je te ferais remarquer que tu as tendance à mélanger haute disponibilité et scalabilité. Bien que ces deux notions soient souvent liées, elles ne se recouvrent pas totalement. En particulier, pour la scalabilité, respecter certains grands principes est souvent moins important que l'expérience empirique. L'exemple typique est l'utilisation d'un cache : on cache telles ou telles données en testant et en regardant ce qui marche le mieux. Cela aide grandement à la montée en charge à un point tel que le site ne peut plus fonctionner sans un cache "chaud", ce qui est loin d'être idéal pour la haute disponibilité.