Cette version marque le passage du dépôt de développement sur GitHub en lieu et place du dépôt SVN, ainsi que la gestion de projet sur Lighthouse au lieu de Trac.
Cela a permis, selon l'équipe de développement, une meilleure contribution au projet avec plus de 1600 patchs provenant de 1400 contributeurs différents.
![[en]](../images/en.png)
Ruby on Rails (709 hits)-
L'annonce sur le blog RoR (261 hits)
-
Lighthouse (813 hits)
-
GitHub (504 hits)
-
Explication des nouveautés (438 hits)
-
Screencasts (513 hits)
> Lire la dépêche (63 commentaires, moyenne: 2,8).
Vous avez demandé le commentaire #937543.
Run by 
Cette page a été générée par Templeet en 0.1103s (dont 0.0098 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Et du côté des perfs ?
A l'époque où je m'intéressais à Ruby, il était question de performances un peu en retrait par rapport à ses concurrents. Qu'en est-il aujourd'hui ?
[^]Re: Et du côté des perfs ?
J'ai l'impression que les reproches faits à Rails en général (même si ruby n'a jamais été considéré comme très rapide) étaient plus liés à sa "scalabilité" (comment ça se traduit ça ?) qu'à ses performances proprement dites. En tous cas de très gros sites fonctionnent avec Rails et semblent tourner convenablement.
De plus de nombreuses solutions ont été développées au-delà de FastCGI pour offrir de meilleures performances (Mongrel, Thin, mod_rails...).
[^]Re: Et du côté des perfs ?
« Montée en charge »
[^]Re: Et du côté des perfs ?
GitHub, YellowPages, Twitter et Friends for Sales sont de "grosses applis" tournant parfaitement sous Rails.
Pour info, Friends for Sales, c'est grosso modo 200 requetes/sec et 300 millions de pages vues par mois.
T'as une appli plus gourmande à développer? :)
Depuis la version 2.0, le couple Ruby / Rails est devenu très performant sur des architectures high scability.
Puis aujourd'hui, les perfs ne veulent plus dire grand chose car les applications gourmandes sont éclatées en services (Amazon EC2, SimpleDB, S3, etc...). Bref, le langage est de moins en moins prépondérant face à une architecture bien pensée.
[^]Re: Et du côté des perfs ?
8000 requêtes seconde, c'est ce que délivre un lighthttpd en local sur des fichiers statiques.
D'accord il y a la bande passante, mais 200 requêtes secondes, c'est peu. Un serveur mutualisé chez ovh doit fournir bien plus.
[^]Re: Et du côté des perfs ?
Tu m'indiqueras quels site sympa tu utilises avec des "fichiers statiques".
Tes perfs brutes n'ont aucun intérêt. Branche toi un peu sur les problémes de montée en charge et fais nous suivre TON site dynamique avec base de données (bien entendu...) chez ovh capable de supporter plus de 200 requetes secondes, je serais le premier à t'embaucher.
Je ne savais pas que Sylvain Mirouf s'était mis au libre...
[+] [^]Re: Et du côté des perfs ?
La base de donnée c'est par définition le problème de toute architecture qui veut monter en charge...
Un site c'est bien plus que ca !
C'est pas le manque de présentation sur slideshare ou sur google engEDU video qui manquent pour comprendre cela...
[^]Re: Et du côté des perfs ?
Sur la plupart des serveurs que j'ai mis en place qui utilisent Rails, les fichiers statiques sont servis aussi vite que peut les servir apache, ça ne passe même pas par Rails. C'est sur les pages dynamiques que les comparaisons de performance sont intéressantes.
[^]Re: Et du côté des perfs ?
Pour note, je fais du rails.
Ce que je veux dire, c'est que s'extasier sur un gros site en prod juste pour dire qu'il délivre 200 pages secondes, c'est un peu ironique.
[^]Re: Et du côté des perfs ?
Ce que tu décris ici est un système distribué, et effectivement c'est le seul moyen de supporter la montée en charge et la haute dispo.
Maintenant je ne savais pas que ruby était capable d'être complètement asyncrhone et permettait de "deleguer" des operations à des processus concurrents permettant dans s'occuper de la transaction en cours pendant que l'internaute en face à dejà reçu une réponse à sa requète.
Tu oublies aussi de parler de tous les artifices nécessaires comme memcached ou xmpp pour twitter. (twitter n'est pas un modèle de stabilité voir les récents articles sur techcrunch)
Ces briques logicielles sont fondamentales pour ces services...
Bâtir de la haute dispo c'est tout simplement gérer les évènements de manière asynchrone.
Une requète à un service externe signifie que ce service retourne tout de suite un token qui va permettre à l'appelant d'être informé de la bonne fin ou pas du traitement demandé.
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.
Une architecture scalable se construit avec des technologies capables de gérer la concurrence. Que ce soit des threads ou des processus; il n'est pas envisageable d'avoir un seul processus au déroulement purement séquentiel pour répondre à une requète.
Ne serait que mettre à jour un compteur, il est n'est pas "normal" de faire l'incrément de ce compteur dans le même processus que celui qui sert la requète. A la place il faut que le processus de traitement de la requète fasse lui même un appel à un service d'incrément de compteur (avec un timeout) et continue son travail. Le processus qui gère l'incrément à tout le loisir pour mettre à jour toutes les ressources liées. Mais en aucun cas un perturbation du réseau pour joindre une des ressources n'aura impacter la réponse à l'utilisateur.
Pour faire simple avec un concept compliqué: la scalabilité c'est ajouter ou enlever des machines de manières transparente, cela signifie que les temps d'exécution observé par l'internaute doivent toujours être semblables.
Un timeout pour toutes les opérations asynchrones et des processus dédiées pour les opérations de types entrée sortie.
Est-ce que ruby sait tirer profit des processeurs multicore ?
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 ?
"Puis aujourd'hui, les perfs ne veulent plus dire grand chose car les applications gourmandes sont éclatées en services (Amazon EC2, SimpleDB, S3, etc...). Bref, le langage est de moins en moins prépondérant face à une architecture bien pensée."
Un langage adapté, et ce n'est pas le cas de ruby.
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...
Relis tout ce qu'à ecrit Zen Shaw, auteur de mongrel, et ce qu'il pense de la communauté ruby... Bref creuse le sujet de la scalabilité, car tu fais fausse route...
[^]Re: Et du côté des perfs ?
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...
Pour le web Ruby on Rails ca été quand même un évènement important dans le développement web. Il a permis d'imposer le modèle MVC qui simplifie le développement et la maintenance. Qui voudrait de nos jour développer sans un tel framework ? Que ce soit en Python, PHP ou Java, tous possèdent leur framework, avec plus ou moins de bonheur, sur le modèle de Rails.
Pour ce qui est du non web, demande à http://metasploit3.com/ ,http://reductivelabs.com/trac/puppet , http://www.snapvine.com/code/ragi/ , les utilisateurs de QtRuby, FxRuby , etc si Ruby est un langage sans intérêt ...
Tu parles de Erlang et je suis entièrement d'accord avec toi, il a été conçu pour la concurrence. Mais aussi bien soit-il (quoi que la syntaxe est plutôt repoussante) sans un framework web digne de ce nom il ne pourra percer (quoique à voir ce que donnera Erlyweb http://erlyweb.org/ (http://twoorl.com est une bonne démo)) et se cantonnera aux backends (tel que le chat de facefook) ce qui n'est pas si mal.
Perso je ne crois plus aux langages ultimes, Rails et Merb font leur preuves coté frontal web, mais une archi qui prétent être haute dispo nécessite de fait un mixage de langages adaptés à leur contexte. Twitter utilise entre autre Erlang sur leur backend, ainsi que Facebook (http://developers.facebook.com/thrift/).
Il n'existe pas un langage adapté à tout.
Quant à Zen Shaw il me semble pas mal trollesque comme personnage.
RubyFrance
[+] [^]Re: Et du côté des perfs ?
Pour le web Ruby on Rails ca été quand même un évènement important dans le développement web. Il a permis d'imposer le modèle MVC qui simplifie le développement et la maintenance. Qui voudrait de nos jour développer sans un tel framework ? Que ce soit en Python, PHP ou Java, tous possèdent leur framework, avec plus ou moins de bonheur, sur le modèle de Rails.
Ah Ruby a inventé le MVC pour le Web ?
Et moi qui croyait bêtement que Struts était le précurseur.
et que RoR n'avait apporté que la mouvance de "convention over configuration"
[^]Re: Et du côté des perfs ?
c'est ptêtre pour ça qu'il parlait "d'imposer" et non d'inventer...
Car qu'on apprécie ou non Rails, il faut bien avouer que depuis qu'il c'est mis à faire du bruit les autres projets (qu'ils existent précédemment ou non) on avancé plus vite (et ce qq soit le langage, php, java, python, ...)
[^]Re: Et du côté des perfs ?
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 ?
>> Est-ce que ruby sait tirer profit des processeurs multicore ?
> Oui, il suffit de lancer plusieurs processus.
T'es sérieux là ?
[^]Re: Et du côté des perfs ?
Pourquoi est ce que ce serait bête ? Les plus puissant serveurs comme Apache commencent par lancer X instances avant d'utiliser des threads à l'intérieur. Pour servir des pages ce genre de modèle va très bien et c'est une très bonne manière d'augmenter les performances de ruby (et d'utiliser plusieurs CPU) en attendant la version 2 et une nouvelle vm.
[^]Re: Et du côté des perfs ?
C'est bête parce que ça veut dire que Ruby profite autant du multicore qu'un script shell, et ce n'est même pas dû à Ruby lui-même mais à l'OS, et aussi qu'il faut s'emmerder à gérer plusieurs processus (et leur inter-communication).
[^]Re: Et du côté des perfs ?
Tu t'égares, on parle depuis le début du thread d'un serveur web !
Il n'y a normallement pas de communication inter process, mais qu'une bête connection a la DB ou un accès à des fichiers puis la génération d'un rendu....
De toute façon, cela ne sert à rien de s'acharner contre ruby, si ses threads sont merdique c'est parce que son créateur était pas trop porté sur les compilateurs. Maintenant une réécriture est en cours pour ruby 2.0 et il sera de rapidité équivalent a php, perl, python, ...
De toute manière ont s'en fout un peu, à mon avis tout projet d'une grande taille devrait envisager plusieurs languages et pour certains type de frontend ruby va très bien. Et syntaxiquement c'est un de mes langages préféré et je crois que c'est aussi très important.
[^]Re: Et du côté des perfs ?
Je me corrige c'est Zed Shaw :)
pour ceux que cela intéresse ..
[^]Re: Et du côté des perfs ?
> GitHub, YellowPages, Twitter et Friends for Sales sont de "grosses applis" tournant parfaitement sous Rails.
non-non, Twitter ne tourne pas parfaitement du tout, au contraire, ils ont eu de gros problèmes, très médiatisés. et pourtant c'est une appli simple, hein, à peine plus compliquée qu'une tribune.
Windows has no users. It has hostages.
[^]Re: Et du côté des perfs ?
Twitter est bien plus compliqué qu'une simple tribune. Ce ne serait que cela, ils n'auraient aucun problème de scalabilité. Mais twitter est bien plus que cela : l'effet "réseau social" joue un rôle considérable. On peut trouver quantité d'articles sur ce sujet, mais http://www.hueniverse.com/hueniverse/2008/03/on-scaling-a-mi(...) me semble être un bon point de départ pour comprendre les problèmes aux quels sont confrontés les développeurs de twitter.
[^]Re: Et du côté des perfs ?
ah non-non-non, je proteste, Twitter n'est PAS compliqué : au lieu d'avoir deux tables comme pour une tribune, on en a... 3. c'est tout.
le gag comme expliqué dans ton article et d'autres c'est que pour marcher, l'appli doit faire des full-scans et c'est lourd. surtout si des andouilles d'utilisateurs s'amusent à ajouter des centaines d'autres utilisateurs comme "amis". mais ça n'a rien de compliqué dans le principe.
deux autres articles dessus :
http://highscalability.com/scaling-twitter-making-twitter-10(...)
http://www.mooseyard.com/Jens/2007/04/twitter-rails-hammers-(...)
qui dit que en fait SQL est peut-être pas des plus adaptés ici :)
Windows has no users. It has hostages.
[^]Re: Et du côté des perfs ?
Je n'ai pas dit que Twitter était compliqué dans l'absolu, mais qu'il était bien plus compliqué qu'une simple tribune. Le nombre de tables ne fait pas tout, il faut aussi tenir compte du nombre de pages, de l'API, de la gestion des SMS, etc. Note également que les tribunes ne gardent généralement pas d'historique contrairement à Twitter. Bref, c'est comme comparer LinuxFR à un simple blog : c'est un peu la même idée, mais ca n'a pas grand chose à voir en pratique.
surtout si des andouilles d'utilisateurs s'amusent à ajouter des centaines d'autres utilisateurs comme "amis"
Si c'était seulement quelques centaines, ca irait encore, mais certains utilisateurs ont plus de 30 000 "amis" (sic).
[^]Re: Et du côté des perfs ?
c'est la base de données qui fait tout ramer. c'est juste des maths. les jointures c'est quand même un poil vieux comme concept et ca a été un poil étudié depuis le temps.
l'usine à gaz à coté avec des fonctionnalités et des plug-ins à tire-la-rigo c'est pas le problème. au pire ça rend l'expérience de l'utilisateur plus plantogène si un des bidules tombe en rade, mais c'est tout. que ca soit simple ou compliqué (disons, riche) n'a aucune influence sur le coeur de Twitter
> certains utilisateurs ont plus de 30 000 "amis"
*PAN*, rien d'autre à ajouter.
ah si, que y'a rien de neuf sous le soleil, que ça soit ICQ, MSN ou Orkut, les utilisateurs normaux n'ont pas 30 000 contacts dans leur "buddy list".
Windows has no users. It has hostages.
[^]Re: Et du côté des perfs ?
Twitter est compliqué.
Or les "andouilles d'utilisateurs" sont précisément tes utilisateurs, tes clients et ton fond de commerce. Tu peux avoir à gérer 3 tables, cela n'enlève en rien la complexité du projet qui doit gérer des millions de requêtes.
Accessoirement, gérer des milliers d'upload d'avatar à la minute, c'est compliqué. Gérer des milliers d'accès API mal écrit, c'est compliqué. Gérer des milliers d'écriture en base en simultané c'est compliqué.
Que tout ceux qui doutent fasse valoir leur savoir dans de beaux projets francais de telle envergure.
[^]Re: Et du côté des perfs ?
> les "andouilles d'utilisateurs" sont précisément tes utilisateurs.
non. je parle de ceux qui, disons, dépassent les 100 contacts ou font un usage inconsidéré ou abusif du service
dans un autre domaine si c'était un webmail ca serait les vilains spammeurs, par exemple
Windows has no users. It has hostages.
[^]Re: Et du côté des perfs ?
Que tout ceux qui doutent fasse valoir leur savoir dans de beaux projets francais de telle envergure.
Il y a bien mon ancienne équipe qui gérait par un webservice 1 millions d'écriture en 9h avec des pointes à 4 millions sur deux tables différentes, avec bien sûr validation des données par lecture dans deux tables différentes, mais certaines boites concurrentes sont plus proches des 10 millions dans le secteur.
Je peux le dire sans me vanter : je n'en suis pas responsable. Par contre, je te garantis qu'on n'avait pas de souci insupportable pour le gérer.
[^]Re: Et du côté des perfs ?
Ta tribune a une API qui génère 10 fois plus de requête que le site ? Visiblement tu sais pas de quoi tu parles.
RubyFrance
[^]Re: Et du côté des perfs ?
visiblement tu ne sais pas non plus de quoi tu parles : des user agents comme pyCoinCoin ou wmcc ne sont pas des navigateurs web qui "vont sur le site".
mais merci d'avoir joué.
Windows has no users. It has hostages.
[^]Re: Et du côté des perfs ?
ahah, et ces agents génèrent autant de requêtes que ce que reçoit l'API twitter ? :) sacré Gniarf.
RubyFrance
[^]Re: Et du côté des perfs ?
à nombre d'utilisateurs égaux ?
ah zut, tu viens de te rendre compte que c'est pas comparable \o/
Windows has no users. It has hostages.
[^]Re: Et du côté des perfs ?
C'est toi qui vient de te rendre compte que comparer une tribune avec une centaine de users n'est pas comparable avec le volume que traite Twitter. Tu dépasses PgPb en mauvaise fois, c'est pas facile pourtant.
RubyFrance
[^]Re: Et du côté des perfs ?
ah non-non, depuis le début je dis que ca n'a rien de compliqué comme structure et que leurs soucis ce n'est pas que ça soit compliqué mais que ça soit utilisé pour de bon maintenant, c'est tout.
pas de chance, en termes de bases de données ils sont dans un cas très défavorable et en fait SQL ou les bases relationnelles sont pas bien bien taillées pour ce cas.
en fait c'était avant. les esprits attentifs auront lu les URLs qui sont passées et auront compris de suite pourquoi l'un des gus avait comparé Twitter à l'email, ou plus généralement à acheminer et délivrer des messages, et que Starling est justement... une message queue :
http://dev.twitter.com/2008/01/announcing-starling.html
Windows has no users. It has hostages.
[^]Re: Et du côté des perfs ?
En fait à une époque on critiquais surtout Ruby on Rails pour la difficulté de déployement.
Aujourd'hui tu balances un mod_rails (renommé Passenger en fait) sur un Apache et tu déployes avec un simple drop de l'appli, comme une appli PHP de base et ça fonctionne out of the box.
Pouvoir déployer des belles applications basée sur un framework ultra sympa comme Rails aussi simplement qu'une banale appli PHP, saykewl :). Aucune raison de pas switcher.
Je trolle mais AMHA actuellement Rails c'est clairement le meilleur outil de développement Web existant. J'ai aussi la chance de pouvoir développer avec professionnellement.
Pour rester objectif, je continue de zieuter autour pour voir la concurrence mais elle est encore loin derrière.
[^]Re: Et du côté des perfs ?
Seaside ? ( http://www.seaside.st/ )
J'ai essayé, ça semble super sympa mais pas forcément facile d'approche. Surtout du fait d'un manque de documentation et d'un changement profond d'habitudes à l'utilisation de SmallTalk.
[^]Re: Et du côté des perfs ?
Pouvoir déployer des belles applications basée sur un framework ultra sympa comme Rails aussi simplement qu'une banale appli PHP, saykewl :). Aucune raison de pas switcher.
C'est trop gros, je peux pas laisser passer ça.
Mais quand tu veux gérer finement des droits sur des dizaines de répertoires avec autant d'utilisateurs, que tu as par dessus des impératifs sécurité (du style pas de shell pour apache), qu'il faut envoyer des mails qui n'arrivent pas directement dans les boîtes spam et que tu travailles avec des devs qui sont outré parce que tu refuse qu'ils fassent des exec à tout va et que de toute façon leur appli elle marche bien sur leur easyphp. Quand tu t'encaisse 18 millions de requêtes par jours, que tu est réveillé la nuit parce qu'un abruti à réussie à coder une redirection 301 récursive ou qu'Apche 2.2 (ah t'avais dit qu'il fallait la 1.3.41) c'est vautré parce qu'un cron a fait un graceful alors qu'arrivait un trop gros post ... ben figure toi que même php c'est pas simple.
L'avantage de de montgrel / BDD / frontal web, c'est que c'est un modèle 3 tiers propre et scalable. Qui t'évite justement les affres d'un mod_php tout en un.
Mes deux cents