Nouveau sur Rails, ce type de performance est-il normal?

Question

J'ai une application et il est seul contrôleur, une action est ainsi configuré:

def do_call 
    response = <<EOF 
<real-time-stat> 
<awt type="integer">1</awt> 
<cc type="integer">5</cc> 
<cp type="integer">0</cp> 
<dc type="integer">0</dc> 
<ef type="float">100.0</ef> 
<rc type="integer">6</rc> 
<sl type="float">100.0</sl> 
<state type="integer">0</state> 
<ts type="datetime">2009-07-24T10:36:57Z</ts> 
<wc type="integer">0</wc> 
<wprc type="float">0.0</wprc> 
<real-time-stat> 
EOF 
    respond_to do |format| 
     format.xml { render :xml => response } 
    end 
    end 

Ceci est un test pour une action qui, à l'avenir, récupérer les champs d'une base de données MySQL. Cependant, en exécutant ce code en mode production, à partir d'un LOCAL serveur WEBrick sur le port 3000 fonctionnant sur un Pentium 4 (un peu vieux, mais dual core), j'obtiens des temps de réponse (mesurés par YSlow, un Yahoo! add-on pour Firebug) de 175 à 500 millisecondes (très fluctuant)!

C'est normal? Est-ce que je le fais mal? Considérant que je souhaite agréger plusieurs requêtes dans une seule réponse et XML-ify toutes (pour utiliser avec ActiveResource), je reçois des cloches en disant qu'il ne peut pas évoluer ...: |

Merci pour vos commentaires!

EDIT: changer en Mongrel ne change pas beaucoup la situation, toujours 175-300 ms par réponse. Cependant, les journaux montrent 0 à 15 ms par requête "terminée" (200 OK). La différence est-elle attribuable au rendu de XML par Firefox? Sinon, d'où cela vient-il?

Answer 1

Si vous utilisez un serveur Web en local et que vous utilisez Firefox pour mesurer les performances, vous obtiendrez des résultats erratiques, trompeurs et douteux. Essayez d'éteindre tout sauf votre serveur Web et utilisez ab ou HTTPerf pour obtenir une mesure plus fiable des performances.

Si vous constatez toujours des temps de réponse faibles pour seulement cracher une chaîne, un bon outil est RubyProf, que vous pouvez exécuter et voir où Rails passe du temps.

Answer 2

Tout ce que je peux penser est d'utiliser un serveur web différent. webrick est très lent. L'utilisation de Mongrel ou Thin vous donnerait de meilleures performances.

En outre, même si vous êtes en mode de production, vérifiez simplement les paramètres de configuration production.rb et assurez-vous que la mise en cache des classes, etc., est encore activée.

Answer 3

Réponse spontanée: n'utilisez pas WebRick. C'est lent. Vraiment lent. Installez mongrel et Rails l'utilisera automatiquement. En production, utilisez mongrel ou passager.

Answer 4

Webrick est lent. Essayez de l'exécuter à nouveau dans une configuration Passenger sympa, puis faites un rapport.

Answer 5

Il y a plusieurs implications qui font que votre test n'est pas trop représentatif. Laissez-moi vous expliquer quelques-uns:

1. Vous test en cours dans un environnement de développement. L'environnement de développement (défini dans config/environments/development.rb) est largement différent de celui de production (défini dans config/environments/development.rb). Tout d'abord, il ne met pas en cache vos classes, de sorte que la majeure partie de vos bibliothèques d'applications est rechargée à n'importe quelle requête. En production, Rails met en cache vos objets au démarrage et n'analyse plus la base de code. C'est un boost de super-performance.

2. Comme on vous l'a dit, vous utilisez le pire serveur Web disponible pour fonctionner. Vous devriez utiliser Mongrel ou, pour lancer un véritable benchmark, vous devriez utiliser le même serveur que vous allez utiliser en production.

3. Il est souvent une bonne règle d'exécuter des tests sur un environnement égal ou similaire à celui final. Lancer un test en mode développement et essayer de deviner comment il fonctionnera en ligne ne vous fournit aucune bonne information.

4. Vous avez perdu le cache. Rails fournit plusieurs niveaux de mise en cache différents. Pour améliorer vos performances, vous pouvez envisager de mettre en cache vos demandes de modèle et/ou vos réponses avec la mise en cache des pages/actions/fragments.En outre, vous pouvez utiliser les en-têtes HTTP qui envoient 304 en-têtes HTTP lorsque le contenu n'est pas modifié et configurer un proxy inverse.

5. Pour ce cas précis de réponse, vous pouvez sauter toute l'action Rails/pile de contrôleur et mettre en œuvre une Rails :: couche de métal afin que votre réponse sera servi dès qu'il est prêt

Answer 6

Enveloppez votre appel à

start = Time.now 
    ... 
    elapsed_time = Time.now - start 

et voir combien de secondes il faut.

D'autres tests seront peu fiables sur votre plate-forme de dev jusqu'à ce que vous le déployer sur le serveur de productions

Answer 7

WEBrick fait une recherche DNS inversée sur la connexion IP par défaut. En d'autres termes, il essaie de voir si votre adresse IP est associée à un nom de domaine. Ceci est inutile et prend trop de temps, vous pouvez donc le désactiver.

Ouvrez le fichier "l/ruby ​​/ lib/ruby ​​/ 1.9.1/webrick/config.rb" et localisez la ligne avec ": DoNotReverseLookup => nil". Remplacez zéro par true.

Profitez-en!