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

#p#

N+1 查詢問題

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

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

答案：上述代碼生成了一個查詢外加 @posts 內(nèi)的每行一個查詢。由于每查詢的負(fù)荷，這可能會成為一個很大的挑戰(zhàn)。罪魁禍?zhǔn)资菍?p.category.name 的調(diào)用。這個調(diào)用只應(yīng)用于該特定的 post 對象，而不是整個 @posts 數(shù)組。幸好，通過使用立即加載，我們可以修復(fù)這個問題。

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

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

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

測試 N+1

使用清單 3 內(nèi)的腳本，可以發(fā)現(xiàn)查詢可以達(dá)到 — 多慢 — 或多快。 清單 3 展示了如何在一個獨(dú)立腳本中使用 ActiveRecord 來建立一個數(shù)據(jù)庫連接、定義表并加載數(shù)據(jù)。然后，可以使用 Ruby 的內(nèi)置基準(zhǔn)測試庫來查看哪種方式更快，快多少。

清單 3. 立即加載基準(zhǔn)測試腳本  
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 個對象進(jìn)行循環(huán)操作的速度如何。為了運(yùn)行此腳本，您可能需要用適合于您的本地環(huán)境的參數(shù)替換此腳本頂部的這些數(shù)據(jù)庫連接參數(shù)。此外，需要創(chuàng)建一個名為 test 的 MySQL 數(shù)據(jù)庫。最后，您還需要 ActiveRecord 和 faker 這兩個 gem，二者可通過運(yùn)行 gem install activerecord faker 獲得。 在我的機(jī)器上運(yùn)行此腳本生成的結(jié)果如清單 4 所示。

清單 4. 立即加載的基準(zhǔn)測試腳本輸出  
-- 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 倍。當(dāng)然，具體的輸出取決于您的特定情況，但立即加載可明顯導(dǎo)致顯著的性能改善。

#p#

嵌套的立即加載

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

清單 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 問題，但修復(fù)的語法卻沒有那么明顯，因為這里所使用的是關(guān)系的關(guān)系。那么如何才能立即加載嵌套關(guān)系呢？正確的答案是使用 :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%>  

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

間接的立即加載

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

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

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

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

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

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

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

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

一種方式是使用緩存技術(shù)。Rails V2.1 內(nèi)置了簡單的緩存訪問。使用 Rails.cache.read、 Rails.cache.write 及相關(guān)方法，可以輕松創(chuàng)建自己的簡單緩存機(jī)制，并且后端可以是一個簡單的內(nèi)存后端、一個基于文件的后端或一個分布式緩存服務(wù)器。

當(dāng)然，并不是所有的 Rails 問題都與查詢的數(shù)量有關(guān)。

#p#

Rails 分組和聚合計算

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

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

相反，Rails 提供了一系列的分組和聚合函數(shù)?？梢韵袂鍐?11 所示的那樣使用它們。

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

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

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

用 Rails 定制 SQL

假設(shè)有這樣一個表，內(nèi)含人的職業(yè)、年齡以及在過去一年中涉及到他們的事故的數(shù)量?？梢允褂靡粋€定制 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 

這個腳本應(yīng)該能生成清單 13 所示的結(jié)果。

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

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

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

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

結(jié)束語

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

原文作者：David Berube

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

【編輯推薦】

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