最后，不要忘記使用類似 Firebug、yslow、Ping 和 tracert 這樣的工具來檢測性能問題是來自于網絡還是資源加載問題。接下來，讓我們來看具體的一些 Rails 性能問題及其解決方案。

#p#

N+1 查詢問題

N+1 查詢問題是 Rails 應用程序最大的問題之一。例如，清單 1 內的代碼能生成多少查詢？此代碼是一個簡單的循環，遍歷了一個假想的 post 表內的所有 post，并顯示 post 的類別和它的主體。

清單 1. 未優化的 Post.all 代碼  
<%@posts = Post.all(@posts).each do |p|%>   
 <h1><%=p.category.name%>h1> 
 <p><%=p.body%>p> 
<%end%> 

答案：上述代碼生成了一個查詢外加 @posts 內的每行一個查詢。由于每查詢的負荷，這可能會成為一個很大的挑戰。罪魁禍首是對 p.category.name 的調用。這個調用只應用于該特定的 post 對象，而不是整個 @posts 數組。幸好，通過使用立即加載，我們可以修復這個問題。

立即加載 意味著 Rails 將自動執行所需的查詢來加載任何特定子對象的對象。Rails 將使用一個 JOIN SQL 語句或一個執行多個查詢的策略。不過，假設指定了將要使用的所有子對象，那么將永遠不會導致 N+1 的情形，在 N+1 情形下，一個循環的每個迭代都會生成額外的一個查詢。清單 2 是對 清單 1 內代碼的修訂，它使用了立即加載來避免 N+1 問題。

清單 2. 用立即加載優化后的 Post.all 代碼  
<%@posts = Post.find(:all, :include=>[:category]  
 @posts.each do |p|%>   
 <h1><%=p.category.name%>h1> 
 <p><%=p.body%>p> 
<%end%> 

該代碼最多生成兩個查詢，而不管在此 posts 表內有多少行。當然，并不是所有情況都如此簡單。處理復雜的 N+1 查詢情況需要更多的工作。那么做這么多努力值得么？讓我們來做一些快速的測試。

測試 N+1

使用清單 3 內的腳本，可以發現查詢可以達到 — 多慢 — 或多快。 清單 3 展示了如何在一個獨立腳本中使用 ActiveRecord 來建立一個數據庫連接、定義表并加載數據。然后，可以使用 Ruby 的內置基準測試庫來查看哪種方式更快，快多少。

清單 3. 立即加載基準測試腳本  
require 'rubygems'  
require 'faker'  
require 'active_record'  
require 'benchmark'  
 
# This call creates a connection to our database.  
 
ActiveRecord::Base.establish_connection(  
 :adapter  => "mysql",  
 :host     => "127.0.0.1",  
 :username => "root", # Note that while this is the default setting for MySQL,  
 :password => "",     # a properly secured system will have a different MySQL  
                            # username and password, and if so, you'll need to  
                            # change these settings.  
 :database => "test")  
 
# First, set up our database...   
class Category <  ActiveRecord::Base 
end  
 
unless Category.table_exists?  
 ActiveRecord::Schema.define do  
  create_table :categories do |t|  
    t.column :name, :string  
  end  
 end   
end  
 
Category.create(:name=>'Sara Campbell\'s Stuff')  
Category.create(:name=>'Jake Moran\'s Possessions')  
Category.create(:name=>'Josh\'s Items')  
number_of_categories = Category.count  
 
class Item <  ActiveRecord::Base   
 belongs_to :category   
end  
 
# If the table doesn't exist, we'll create it.  
 
unless Item.table_exists?  
 ActiveRecord::Schema.define do  
  create_table :items do |t|  
    t.column :name, :string  
    t.column :category_id, :integer   
  end  
 end   
end  
 
puts "Loading data..."  
 
item_count = Item.count  
item_table_size = 10000 
 
if item_count < item_table_size 
 (item_table_size - item_count).times do  
  Item.create!(:name=>Faker.name,   
                 :category_id=>(1+rand(number_of_categories.to_i)))  
 end  
end  
 
puts "Running tests..."  
 
Benchmark.bm do |x|   
 [100,1000,10000].each do |size|   
  x.report "size:#{size}, with n+1 problem" do   
   @items=Item.find(:all, :limit=>size)  
   @items.each do |i|   
    i.category  
   end   
  end   
  x.report "size:#{size}, with :include" do   
   @items=Item.find(:all, :include=>:category, :limit=>size)  
   @items.each do |i|   
    i.category  
   end   
  end   
 end   
end 

這個腳本使用 :include 子句測試在有和沒有立即加載的情況下對 100、1,000 和 10,000 個對象進行循環操作的速度如何。為了運行此腳本，您可能需要用適合于您的本地環境的參數替換此腳本頂部的這些數據庫連接參數。此外，需要創建一個名為 test 的 MySQL 數據庫。最后，您還需要 ActiveRecord 和 faker 這兩個 gem，二者可通過運行 gem install activerecord faker 獲得。 在我的機器上運行此腳本生成的結果如清單 4 所示。

清單 4. 立即加載的基準測試腳本輸出  
-- create_table(:categories)  
  -> 0.1327s  
-- create_table(:items)  
  -> 0.1215s  
Loading data...  
Running tests...  
   user     system      total        real  
size:100, with n+1 problem  0.030000   0.000000   0.030000 (  0.045996)  
size:100, with :include  0.010000   0.000000   0.010000 (  0.009164)  
size:1000, with n+1 problem  0.260000   0.040000   0.300000 (  0.346721)  
size:1000, with :include  0.060000   0.010000   0.070000 (  0.076739)  
size:10000, with n+1 problem  3.110000   0.380000   3.490000 (  3.935518)  
size:10000, with :include  0.470000   0.080000   0.550000 (  0.573861) 

在所有情況下，使用 :include 的測試總是更為迅速 — 分別快 5.02、4.52 和 6.86 倍。當然，具體的輸出取決于您的特定情況，但立即加載可明顯導致顯著的性能改善。

#p#

嵌套的立即加載

如果您想要引用一個嵌套的關系 — 關系的關系，又該如何呢？ 清單 5 展示了這樣一個常見的情形：循環遍歷所有的 post 并顯示作者的圖像，其中 Author 與 Image 是 belongs_to 的關系。

清單 5. 嵌套的立即加載用例  
@posts = Post.all   
@posts.each do |p|    
 <h1><%=p.category.name%>h1> 
 <%=image_tag p.author.image.public_filename %>   
 <p><%=p.body%>   
 <%end%>  

此代碼與之前一樣亦遭遇了相同的 N+1 問題，但修復的語法卻沒有那么明顯，因為這里所使用的是關系的關系。那么如何才能立即加載嵌套關系呢？正確的答案是使用 :include 子句的哈希語法。清單 6 給出了使用哈希語法的一個嵌套的立即加載。

清單 6. 嵌套的立即加載解決方案  
@posts = Post.find(:all, :include=>{ :category=>[],  
        :author=>{ :image=>[]}} )  
@posts.each do |p|    
 <h1><%=p.category.name%>h1> 
 <%=image_tag p.author.image.public_filename %>   
 <p><%=p.body%>   
 <%end%>  

正如您所見，您可以嵌套哈希和數組實量（literal）。請注意在本例中哈希和數組之間的惟一區別是哈?？梢院星短椎淖訔l目，而數組則不能。否則，二者是等效的。

間接的立即加載

并非所有的 N+1 問題都能很容易地察覺到。例如，清單 7 能生成多少查詢？

清單 7. 間接的立即加載示例用例  
<%@user = User.find(5)  
    @user.posts.each do |p|%>     
      <%=render :partial=>'posts/summary',  :locals=>:post=>p  
     %> <%end%> 

當然，決定查詢的數量需要對 posts/summary partial 有所了解。清單 8 中顯示了這個 partial。

清單 8. 間接立即加載 partial: posts/_summary.html.erb   
<h1><%=post.user.name%>h1> 

不幸的是，答案是 清單 7 和 清單 8 在 post 內每行生成一個額外查詢，查找用戶的名字 — 即便 post 對象由 ActiveRecord 從一個已在內存中的 User 對象自動生成。簡言之，Rails 并不能關聯子記錄與其父記錄。

修復方法是使用自引用的立即加載?；旧?，由于 Rails 重載由父記錄生成的子記錄，所以需要立即加載這些父記錄，就如同父與子記錄之間是完全分開的關系一樣。代碼如清單 9 所示。

清單 9. 間接的立即加載解決方案  
<%@user = User.find(5, :include=>{:posts=>[:user]})  
...snip... 

雖然有悖于直覺，但這種技術與上述技術的工作原理大致相似。但是，很容易使用這種技術進行過多的嵌套，尤其是在體系結構復雜的情況下。簡單的用例還好，比如 清單 9 內所示的，但繁復的嵌套也會出問題。在一些情況下，過多地加載 Ruby 對象有可能會比處理 N+1 問題還要緩慢 — 尤其是當每個對象并沒有被整個樹遍歷時。在該種情況下，N+1 問題的其他解決方案可能更為適合。

一種方式是使用緩存技術。Rails V2.1 內置了簡單的緩存訪問。使用 Rails.cache.read、 Rails.cache.write 及相關方法，可以輕松創建自己的簡單緩存機制，并且后端可以是一個簡單的內存后端、一個基于文件的后端或一個分布式緩存服務器。

當然，并不是所有的 Rails 問題都與查詢的數量有關。

#p#

Rails 分組和聚合計算

您可能遇到的一個問題是在 Ruby 所做的工作本應由數據庫完成。這考驗了 Ruby 的強大程度。很難想象在沒有任何重大激勵的情況下人們會自愿在 C 中重新實現其數據庫代碼的各個部分，但很容易在 Rails 內對 ActiveRecord 對象組進行類似的計算。但是，Ruby 總是要比數據庫代碼慢。所以請不要使用純 Ruby 的方式執行計算，如清單 10 所示。

清單 10. 執行分組計算的不正確方式  
all_ages = Person.find(:all).group_by(&:age).keys.uniq  
oldest_age = Person.find(:all).max 

相反，Rails 提供了一系列的分組和聚合函數。可以像清單 11 所示的那樣使用它們。

清單 11. 執行分組計算的正確方式  
all_ages = Person.find(:all, :group=>[:age])    
oldest_age = Person.calcuate(:max, :age) 

ActiveRecord::Base#find 有大量選項可用于模仿 SQL。更多信息可以在 Rails 文檔內找到。注意，calculate 方法可適用于受數據庫支持的任何有效的聚合函數，比如 :min、:sum 和 :avg。此外，calculate 能夠接受若干實參，比如 :conditions。查閱 Rails 文檔以獲得更詳細的信息。

不過，并不是在 SQL 內能做的所有事情在 Rails 內也能做。如果插件不夠，可以使用定制 SQL。

用 Rails 定制 SQL

假設有這樣一個表，內含人的職業、年齡以及在過去一年中涉及到他們的事故的數量?？梢允褂靡粋€定制 SQL 語句來檢索此信息，如清單 12 所示。

清單 12. 用 ActiveRecord 定制 SQL 的例子  
sql = "SELECT profession,  
              AVG(age) as average_age,    
              AVG(accident_count)   
         FROM persons   
        GROUP   
           BY profession"  
 
Person.find_by_sql(sql).each do |row|     
  puts "#{row.profession}, " << 
       "avg. age: #{row.average_age}, " << 
       "avg. accidents: #{row.average_accident_count}"  
end 

這個腳本應該能生成清單 13 所示的結果。

清單 13. 用 ActiveRecord 定制 SQL 的輸出  
Programmer, avg. age: 18.010, avg. accidents: 9  
System Administrator, avg. age: 22.720, avg. accidents: 8 

當然，這是最簡單的例子。您可以自己想象一下如何能將此例中的 SQL 擴展成一個有些復雜性的 SQL 語句。您還可以使用 ActiveRecord::Base.connection.execute 方法運行其他類型的 SQL 語句，比如 ALTER TABLE 語句，如清單 14 所示。

清單14. 用 ActiveRecord 定制非查找型 SQL  
ActiveRecord::Base.connection.execute "ALTER TABLE some_table CHANGE COLUMN..." 

大多數的模式操作，比如添加和刪除列，都可以使用 Rails 的內置方法完成。但如果需要，也可以使用執行任意 SQL 代碼的能力。

結束語

與所有的框架一樣，如果不多加小心和注意，Ruby on Rails 也會遭遇性能問題。所幸的是，監控和修復這些問題的技術相對簡單且易學，而且即便是復雜的問題，只要有耐心并對性能問題的源頭有所了解，也是可以解決的。

原文作者：David Berube

原文鏈接：http://www.ibm.com/developerworks/cn/opensource/os-railsn1/index.html

【編輯推薦】

1. Ruby on Rails性能優化七劍
2. 基于Ruby On Rails開發高品質Web應用
3. Ruby on Rails應用技巧全解析
4. 大改動小變化 Ruby On Rails 3蓄勢待發
5. 跑起來吧 Ruby on Rails開發初體驗