Twitter mais pas cave
C’est un article concernant Twitter qui m’a fait réfléchir. On y disait qu’ils étaient aux prises avec des problèmes de performance qu’ils attribuaient à leur choix de langage / plate-forme : Ruby on Rails.
Trip de programmeur
Comme l’article visait surtout des lecteurs-programmeurs, on y trouvait surtout des éléments techniques tel que des comparaisons sur la vitesse d’exécution de langages. La question qui m’intéressait est : est-ce que Twitter a fait le bon choix? Ils ont choisi la rapidité de développement au détriment des performances. En bout de ligne, leur service a complètement explosé en terme de popularité. On parle de plus de 10 000 requêtes à la seconde.
Surfer la vague ou manquer le bateau
Pendant qu’on débat sur des sujets comme les choix de langages, d’autres développent des nouveaux services dont des milliers d’usagers ne pourront se passer d’ici quelques mois. Oui, c’est bon d’en parler quand même. C’est bon aussi de rester conscient qu’il y a certaines configurations qui peuvent donner une mauvaise expérience à l’usager à cause d’un manque de rapidité. Reste que le plus important pour l’entreprise c’est de rendre le produit fonctionnel le plus vite possible, surtout dans le monde du Web 2.0.
T’as un beau problème quand…
…t’es obligé de retravailler ton site parce que “trop de gens” essayent d’y accéder. Personnellement, je travaille à avoir ce genre de problème. Je souhaite que mon hébergeur m’harcèle parce que je pète mes quotas. Avec 10 000 visites / seconde, pas besoin d’avoir beaucoup de publicité pour être rentable. J’ai aucune espèce de données qui me permettent de le calculer mais je vois mal comment ça ne pourrait pas être payant. Même si tu dois engager en catastrophe des vieux administrateurs Linux et programmeurs séniors, barbus, pigistes à un prix exorbitant en passant une annonce sur ton site. Oui, ils l’ont fait ici.
Éthique
Ce n’est pas un manque de respect envers les premiers usagers de leur offrir un service un peu plus lent si le nombre d’usager monte en flèche. C’était peut-être même la seule façon de réussir à monter un projet comme ça. On peut s’attendre à ce que Twitter refasse leur leçon et revienne avec un service aussi fiable et rapide qu’avant.
Je suis en partie d’accord avec ce que tu dis. Par contre :
“C’est bon aussi de rester conscient qu’il y a certaines configurations qui peuvent donner une mauvaise expérience à l’usager à cause d’un manque de rapidité. Reste que le plus important pour l’entreprise c’est de rendre le produit fonctionnel le plus vite possible”
Si le produit n’atteint pas un niveau de performance décent, il devient moins fonctionnel aux yeux de ses utilisateurs. Je ne sais pas vraiment à quoi attribuer la lenteur de Twitter. Ruby? Rails? Programmation déficiente (Je dis ça en tout respect envers les développeurs. Ça arrive d’écrire du code pas trop performant…) ?
Quoi qu’il en soit, je suis d’accord avec toi quand tu dis que c’est un “beau problème”. Les gens derrière Twitter auront une importante décision à prendre (si elle n’a pas déjà étéprise… le site répond rapidement au moment où j’écris ces lignes)
#1 : On achète des nouvelles machines et on change de hosting
#2 : On change de framework (tout recoder… ouch)
#3 : On “tweak” le code pour améliorer la performance
#4 : Un mix de #1 et #3
Faut évidemment pas aller dans les extrêmes. Si l’application répond vraiment trop lentement, c’est clair que les utilisateurs vont pas être satisfait.
Twitter risque de faire un mélange des solutions dont tu parles mais je doute qu’il change tout. C’est au niveau du caching que ça devrait faire la différence comme le problème est surtout relié aux nombres de connexions à la base de données.
Mais d’un autre côté, comment tu veux avoir une cache efficace quand la page change à toutes les millièmes de seconde?
De mon bord, j’imagine que le problème réside pas complètement dans Rails ou Ruby mais dans le mélange de tout ça. La DB est souvent un des points faibles d’une application faque je veux pas imaginer comment elle se sent avec autant de transactions.
On s’entend pour dire que 10000 transactions secondes c’est un peu extrême. Je dirais que pour un problème extrême il faut une solution extrême. Peut-être que c’est juste pas pensable d’utiliser une base de données pour la quantité de requête pour voir la page principale ou pour les nouveaux “messages” qui entrent. J’ai bien l’impression que la solution sera pas nécessairement très chic en arrière.
En bout de ligne, je fais un article pour dire qu’on se soucie trop du côté technique et dans les commentaires on parle juste de ça. Ce que je voulais dire c’est que Twitter a peut-être prit la seule façon de réussir à populariser un service du genre soit en mettant le tout en ligne le plus rapidement possible. Je m’explique mal que ce service puisse gagner autant d’adepte et pourtant y’a des gens complètement fanatiques. Tout ça, ça rien à voir avec Ruby on Rails. C’est cette “science” sur laquelle je m’intérroge.