Benchmarking rails Requêtes ActiveRecord

Question

Je cherche à référencer quelques-unes de mes demandes ActiveRecord dans mon application. Quelle est la façon la plus simple de la console à quelque chose comme référence

User.find_by_name("Joe").id 

contre

User.find(:first, :select => :id, :conditions => ["name = ?","Joe"]).id 

Merci

Answer 1

Utiliser un script/performance/benchmarker:

script/performance/benchmarker 2000 "User.find_by_name('Joe').id" "User.first(:conditions => {:name => 'Joe'}, :select => 'id').id" 

Sur ma machine dev, ce rapports:

  user  system  total  real 
#1  1.110000 0.070000 1.180000 ( 1.500366) 
#2  0.800000 0.050000 0.850000 ( 1.078444) 

Ainsi, la 2ème méthode semble être plus rapide, car il a moins de travail à faire. Bien sûr, vous devez indice de référence sur votre machine de production, en utilisant l'environnement de production:

RAILS_ENV=production script/performance/benchmarker 2000 "User.find_by_name('Joe').id" "User.first(:conditions => {:name => 'Joe'}, :select => 'id').id" 

Il peut changer les conditions un peu pour vous.

Answer 2

En mode de développement chaque requête est chronométré et connecté log/development.log. Vous aurez des lignes comme:

Ad Load (1.4ms) SELECT "ads".* FROM "ads" ORDER BY created_at DESC 

Answer 3

Cette question est un peu ancienne et a besoin d'une réponse à jour. Le moyen le plus simple de comparer la requête en dehors d'un scénario de production serait de l'exécuter en rails console (le script benchmarker n'est plus dans Rails). Vous pouvez ensuite tester simplement la classe Benchmark intégrée dans Ruby. Exécutez ce qui suit dans Rails:

puts Benchmark.measure { User.find_by_name("Joe").id } 
puts Benchmark.measure { User.find(:first, :select => :id, :conditions => ["name = ?","Joe"]).id } 

Je courrais les 5 fois ci-dessus, Rejeter min et max, et prendre le coût moyen des trois points qui restent à déterminer quelle requête va vous donner de meilleures performances .

Ceci est la solution la plus précise pour obtenir le vrai coût d'une requête depuis Rails doesn't show you the cost to actually construct your objects. Donc, alors que @Slobodan Kovacevic la réponse est correcte en ce que le journal vous montre comment log la requête prend, le long ne vous donne pas le temps de construction de l'objet qui peut être moindre pour votre seconde requête puisque vous remplissez un seul champ par rapport à tous les champs utilisateur .