Performance et Ruby on Rails

Parmi les enjeux majeurs d’une application Web, la performance est parfois citée comme un point négatif de Ruby on Rails. L’argument le plus employé est le temps d’execution du langage Ruby sur un jeu d’algorithmes connus. Dans la réalité il s’avère qu’effectivement un certain nombre de sites utilisant Ruby on Rails semblent rencontrer des problèmes de performance… mais pour de toutes autres raisons !

Qu’est-ce que la performance ? Pour un service Web nous pouvons considérer ces indicateurs :
• Temps de réponse à une requête (le client a-t-il reçu son résultat assez vite ?).
• Capacité d’accueil (combien de requêtes puis-je traiter dans une unité de temps).
• Vitesse d’exécution des tâches annexes : envoyer des mails, créer un PDF, générer un rapport statistique…

L’enjeu principal étant bien sûr de garantir de bons indicateurs de performance alors même que votre application a du succès.

Si l’on regarde l’impact du choix d’un Framework sur ces trois sujets, on s’aperçoit qu’il est une toute petite partie du problème. La véritable clef réside dans l’architecture de l’application. Or le choix d’une bonne architecture dépend principalement de l’expérience de l’architecte. Dans le monde des services Web, les personnes détenant cette expérience ont généralement déjà une bonne connaissance d’une technologie comme Java ou PHP et peu (en France) se sont orientés vers Rails.

Heureusement cette expérience est de plus en plus diffusée dans la littérature et sur internet, notamment depuis les déboires de twitter. La recherche « rails scalability » donne de très nombreuses réponses pertinentes. De mon côté je conseille les références suivantes pour démarrer et en savoir plus :
• Le livre Enterprise Rails : qui synthétise sur plusieurs sujets ce que l’on pourrait apprendre en plusieurs années d’expérience.
• L’introduction à Resque par Github qui aborde les autres systèmes de gestion de messages au sein d’une application.

Plus généralement, la lecture des résultats de cas pratiques est souvent riche d’enseignements avec pour exemple l’architecture de LinkedIn dans ce document pdf issu de la Qconf.

Un commentaire »

  1. merci raphael. c’était utile ce billet .

    Commentaire par kannan — 15 août 2010 @ 20 h 55 min

Laisser un commentaire

Nous ne revendons pas les adresses collectées