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 ?
Posté par forc3 . En réponse à la dépêche Ruby on Rails 2.1 disponible. Évalué à 4.
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...