Concurrence et parallelisation dans Ruby et PHP

On vient de demander à l'architecte que je suis de donner son avis sur le langage de programmation Ruby et le framework Ruby On Rails. N'ayant jamais pratiqué ce langage, j'aurais été bien à mal de répondre mais mes différentes lectures (remises à jour rapidement) me permettent de dire que pour une application web "industrielle", je me ferai un peu de souci vis à vis de la rapidité de l'interpréteur que certains jugent lent même si Ruby et RoR permettent de faire gagner des developer cycles sinon des cpu cycles. L'autre souci, mais qui est commun à la plupart des frameworks offrant des facilités de programmation vis à vis des bases de données, est que le programmeur se laisse abuser par la simplicité de développement et oublie qu'une application web nécessitant de bonnes performances ne peut se contenter de requêtes SQL génériques si celles-ci doivent être nombreuses et répétées.

Dans mes lectures de ce soir, je me suis rendu compte que Ruby permettrait de manipuler des threads (ce qui est à mon avis l'une des meilleures features de Java) de qui n'ets pas forcément d'une grand intérêt pour une application Web sauf si l'on considère que celle-ci est un mash-up et doit faire appel à de multiples web services, en essayant de minimiser les temps d'accès à ceux-ci, ainsi que le traitement permettant d'utiliser les résultats qu'ils renvoient. L'utilisation de threads, notamment sur une machine multi-processeurs (ce qui est assez commun de nos jours), permet alors d'assurer de bonnes performances à cette application Web. Malheureusement, j'ai été déçu de lire que les interpréteurs Ruby ne fournissaient pas le support des threads natifs, seuls à même de faire profiter de la puissance des multi-pros.

De la même manière, il n'y a pas à ma connaissance de support des threads natifs ou non dans PHP. Mais il se trouve que l'on peut au moins démarrer des demandes en parallèle et attendre la réponse la plus rapide pour commencer le traitement. Pour cela, il faudra utiliser stream_select, ou de manière plus simple les fonctions multi de curl.

posteur Teorem
horloge lundi 20 août 2007 à 23:03

Lien Permanent du billet : #90
Fil RSS du billet :

Catégorie : Programmation

Commentaires

1. Le mardi 21 août 2007 à 16:53, par Thomas

Ce que tu dis n'est pas faux, cependant des sites performants avec une grosse audience tournent en RoR alors ... ca depend peut etre du type d'application, et des "calculs" que celle-ci doit faire, car pour une application web de base, les mauvaises perfs de l'interpréteur ruby ne sont-elles pas négligeables par rapport aux latences réseaux et aux accès bases ?

PS : avec la sortie de JRuby, je pense qu'il est possible d'accèder aux threads natives (à vérifier) mais je pense qu'un des gros avantages de JRuby est justement la

2. Le mercredi 22 août 2007 à 13:53, par Teorem - site

1) en fait, non, les mauvaises perfs de l'interpréteur ne sont pas négligeables. Une fois que l'on a optimisé les accès aux bases ou aux fichiers (avec du cache notamment), donc en reportant la plus grande partie de la charge totale sur les frontaux, avoir un interpréteur 5 fois moins rapide implique 5 fois plus de machines pour le même nombre de requêtes. Donc une application plus difficilement scalable.

Il n'empêche que l'on se trouve au début de l'utilisation de Ruby, et je suis assez d'accord avec Joel Spolsky (voir www.joelonsoftware.com/it...) même si je n'ai pas envie de prendre de risques maintenant avec ce langage, je serais beaucoup plus confiant dans qqs mois ou années. Il suffit que la communauté Ruby (comme la communauté que Rasmus Lerdorf a montée autour de PHP) se retrousse les manches. Et ils semblent prêts à le faire (voir t-a-w.blogspot.com/2007/0...).

2) pour ce que est des threads, j'ai vu une interview des programmeurs des VM ruby et yarv qui disaient que les threads natifs n'étaient pas à l'ordre du jour pour le moment. Dans YARV, ils étaient utilisés mais avec un blocage au niveau du process qui en font des green threads au final. Et si on veut effectivement utilser des threads, c'est en général pour des raisons de performances donc JRuby n'aiderait pas beaucoup à ce niveau. Surtout qu'il ets moins rapide que ruby 1.8.5 (voir antoniocangiano.com/2007/...)

3. Le mardi 28 août 2007 à 20:31, par Strass - site

En gros, vous ne pratiquez ni Ruby, ni Ruby on Rails, mais vous vous permettez quand même de donner un avis ?

De plus, je note que Spolsky (que je lis régulièrement quand même) n'applique pas ses propres conseils à lui-même ("you really must recognize that there just isn't a lot of experience in the world building big mission critical web systems in Ruby on Rail") puisque leur soft, FogBugz, est écrit avec le language Wasabi, qu'ils ont développé en interne et qui n'est toujours pas très usité...

4. Le mercredi 29 août 2007 à 14:37, par Teorem - site

Oui, bien sûr que je me permet de donner mon avis. D'abord parce que j'ai suffisamment d'expérience dans le monde de l'Internet pour être capable d'établir un certain nombres de critères objectifs me permettant de me faire une opinion au vu de la littérature trouvée sur Internet. Ensuite parce que au moment où j'exprime cette opinion, je définie aussi son contexte et le raisonnement qui m'y a amené, permettant ainsi à ceux qui me lisent d'en appréhender la valeur et les limites.

J'ai moi aussi souris lorsque j'ai lu cette mention de ce langage, mais cela n'enlève rien à l'opinion exprimé dans l'article (et que j'ai peut-être mal retransmis dans le commentaire ci-dessus): le meilleur langage de programmation dépendra tout autant des capacités de ce langage que de son contexte d'utilisation.

Ajouter un commentaire

Les commentaires pour ce billet sont fermés.

Teorem's Blog