Ruby 語言常以其靈活性為人所稱道。正如 Dick Sites 所言，您可以 “為了編程而編程”。Ruby on Rails 擴展了核心 Ruby 語言，但正是 Ruby 本身使得這種擴展成為了可能。Ruby on Rails 使用了該語言的靈活性，這樣一來，無需太多樣板或額外的代碼就可以輕松編寫高度結構化的程序：無需額外工作，就可以獲得大量標準的行為。雖然這種輕松自由的行為并不總是完美的，但畢竟您可以無需太多工作就可以獲得很多好的架構。
例如，Ruby on Rails 基于模型-視圖-控制器（Model-View-Controller，MVC）模式，這意味著大多數 Rails 應用程序都可以清晰地分成三個部分。模型部分包含了管理應用程序數據所需的行為。通常，在一個 Ruby on Rails 應用程序中，模型和數據庫表之間的關系是 1:1；Ruby on Rails 默認使用的對象關系映射（ORM）ActiveRecord 負責管理模型與數據庫的交互，這意味著 Ruby on Rails 程序通常都具有（如果有的話）很少量的 SQL 代碼。第二個部分是視圖，它包含創建發送至用戶的輸出所需要的代碼；它通常由 HTML、JavaScript 等組成。最后的一個部分是控制器，它將來自用戶的輸入轉變為正確的模型，然后使用適當的視圖呈現響應。
Rails 的倡導者通常都樂于將其易用性方面的提高歸功于 MVC 范型 — 以及 Ruby 和 Rails 二者的其他一些特性，并稱很少有程序員能夠在較短的時間內創建更多的功能。當然，這意味著投入到軟件開發的成本將能夠產生更多的商業價值，因此 Ruby on Rails 開發愈發流行。
不過，最初的開發成本并不是事情的全部，還有其他的后續成本需要考慮，比如應用程序運行的維護成本和硬件成本。Ruby on Rails 開發人員通常會使用測試和其他的敏捷開發技術來降低維護成本，但是這樣一來，很容易忽視具有大量數據的 Rails 應用程序的有效運行。雖然 Rails 能夠簡化對數據庫的訪問，但它并不總是能夠如此有效。
Rails 應用程序為何運行緩慢？
Rails 應用程序之所以運行緩慢，其中有幾個很基本的原因。第一個原因很簡單：Rails 總是會做一些假設為您加速開發。通常，這種假設是正確而有幫助的。不過，它們并不總能有益于性能，并且還會導致資源使用的效率低下 — 尤其是數據庫資源。
例如，使用等同于 SELECT * 的一個 SQL 語句，ActiveRecord 會默認選擇查詢上的所有字段。在具有為數眾多的列的情況下 — 尤其是當有些字段是巨大的 VARCHAR 或 BLOB 字段時 — 就內存使用和性能而言這種行為很有問題。
另一個顯著的挑戰是 N+1 問題，本文將對此進行詳細的探討。這會導致很多小查詢的執行，而不是一個單一的大查詢。例如，ActiveRecord 無從知道一組父記錄中的哪一個會請求一個子記錄，所以它會為每個父記錄生成一個子記錄查詢。由于每查詢的負荷，這種行為將導致明顯的性能問題。
其他的挑戰則更多地與 Ruby on Rails 開發人員的開發習慣和態度相關。由于 ActiveRecord 能夠讓如此眾多的任務變得輕而易舉，Rails 開發人員常常會形成 “SQL 不怎樣” 的一種態度，即便在更適合使用 SQL 的時候，也會避免 SQL。創建和處理數量巨大的 ActiveRecord 對象的速度會非常緩慢，所以在有些情況下，直接編寫一個無需實例化任何對象的 SQL 查詢會更快些。
由于 Ruby on Rails 常被用來降低開發團隊的規模，又由于 Ruby on Rails 開發人員通常都會執行部署和維護生產中的應用程序所需的一些系統管理任務，因此若對應用程序的環境知之甚少，就很可能出問題。操作系統和數據庫有可能未被正確設置。比如，雖然并不最優，MySQL my.cnf 設置常常在 Ruby on Rails 部署內保留它們的默認設置。此外，可能還會缺少足夠的監控和基準測試工具來提供性能的長期狀況。當然，這并不是在責怪 Ruby on Rails 開發人員；這是非專業化導致的后果；在有些情況下，Rails 開發人員有可能是這兩個領域的專家。
最后一個問題是 Ruby on Rails 鼓勵開發人員在本地環境中進行開發。這么做有幾個好處 — 比如，開發延遲的減少和分布性的提高 — 但它并不意味著您可以因為工作站規模的減少而只處理有限的數據集。他們如何開發以及代碼將被部署于何處之間的差異可能會是一個大問題。即便您在一個性能良好的輕載本地服務器上處理小規模的數據已經很長一段時間，也會發現對于擁塞的服務器上的大型數據此應用程序會有很明顯的性能問題。
當然，Rails 應用程序具有性能問題的原因可能有很多。查出 Rails 應用程序有何潛在性能問題的最佳方法是，利用能為您提供可重復、準確度量的診斷工具。
檢測性能問題
最好的工具之一是 Rails 開發日志，它通常位于每個開發機器上的 log/development.log 文件內。它具有各種綜合指標：響應請求所花費的總時間、花費在數據庫內的時間所占的百分比、生成視圖所花時間的百分比等。此外，還有一些工具可用來分析此日志文件，比如 development-log-analyzer。
在生產期間，通過查看 mysql_slow_log 可以找到很多有價值的信息。更為全面的介紹超出了本文的討論范圍，更多信息可以在 參考資料 部分找到。
其中一個最強大也是最為有用的工具是 query_reviewer 插件（參見 參考資料）。這個插件可顯示在頁面上有多少查詢在執行以及頁面生成需要多長時間。并且它還會自動分析 ActiveRecord 生成的 SQL 代碼以便發現潛在問題。例如，它能找到不使用 MySQL 索引的查詢，所以如果您忘記了索引一個重要的列并由此造成了性能問題，那么您將能很容易地找到這個列（有關 MySQL 索引的更多信息，參見 參考資料）。此插件在一個彈出的 <div>（只在開發模式下可見）中顯示了所有這類信息。
最后，不要忘記使用類似 Firebug、yslow、Ping 和 tracert 這樣的工具來檢測性能問題是來自于網絡還是資源加載問題。
接下來，讓我們來看具體的一些 Rails 性能問題及其解決方案。
N+1 查詢問題
N+1 查詢問題是 Rails 應用程序最大的問題之一。例如，清單 1 內的代碼能生成多少查詢？此代碼是一個簡單的循環，遍歷了一個假想的 post 表內的所有 post，并顯示 post 的類別和它的主體。
清單 1. 未優化的 Post.all 代碼
|
1
2
3
4
5
|
<%@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 代碼
|
1
2
3
4
5
|
<%@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. 立即加載基準測試腳本
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
|
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::Baseendunless Category.table_exists? ActiveRecord::Schema.define do create_table :categories do |t| t.column :name, :string end endendCategory.create(:name=>'Sara Campbell\'s Stuff')Category.create(:name=>'Jake Moran\'s Possessions')Category.create(:name=>'Josh\'s Items')number_of_categories = Category.countclass Item < ActiveRecord::Base belongs_to :categoryend# 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 endendputs "Loading data..."item_count = Item.countitem_table_size = 10000if 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))) endendputs "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 endend |
這個腳本使用 :include 子句測試在有和沒有立即加載的情況下對 100、1,000 和 10,000 個對象進行循環操作的速度如何。為了運行此腳本，您可能需要用適合于您的本地環境的參數替換此腳本頂部的這些數據庫連接參數。此外，需要創建一個名為 test 的 MySQL 數據庫。最后，您還需要 ActiveRecord 和 faker 這兩個 gem，二者可通過運行 gem install activerecord faker 獲得。
在我的機器上運行此腳本生成的結果如清單 4 所示。
清單 4. 立即加載的基準測試腳本輸出
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
-- create_table(:categories) -> 0.1327s-- create_table(:items) -> 0.1215sLoading data...Running tests... user system total realsize: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 倍。當然，具體的輸出取決于您的特定情況，但立即加載可明顯導致顯著的性能改善。
嵌套的立即加載
如果您想要引用一個嵌套的關系 — 關系的關系，又該如何呢？ 清單 5 展示了這樣一個常見的情形：循環遍歷所有的 post 并顯示作者的圖像，其中 Author 與 Image 是 belongs_to 的關系。
清單 5. 嵌套的立即加載用例
|
1
2
3
4
5
6
|
@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. 嵌套的立即加載解決方案
|
1
2
3
4
5
6
7
|
@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. 間接的立即加載示例用例
|
1
2
3
4
|
<%@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
|
1
|
<h1><%=post.user.name%></h1> |
不幸的是，答案是 清單 7 和 清單 8 在 post 內每行生成一個額外查詢，查找用戶的名字 — 即便 post 對象由 ActiveRecord 從一個已在內存中的 User 對象自動生成。簡言之，Rails 并不能關聯子記錄與其父記錄。
修復方法是使用自引用的立即加載。基本上，由于 Rails 重載由父記錄生成的子記錄，所以需要立即加載這些父記錄，就如同父與子記錄之間是完全分開的關系一樣。代碼如清單 9 所示。
清單 9. 間接的立即加載解決方案
|
1
2
|
<%@user = User.find(5, :include=>{:posts=>[:user]})...snip... |
雖然有悖于直覺，但這種技術與上述技術的工作原理大致相似。但是，很容易使用這種技術進行過多的嵌套，尤其是在體系結構復雜的情況下。簡單的用例還好，比如 清單 9 內所示的，但繁復的嵌套也會出問題。在一些情況下，過多地加載 Ruby 對象有可能會比處理 N+1 問題還要緩慢 — 尤其是當每個對象并沒有被整個樹遍歷時。在該種情況下，N+1 問題的其他解決方案可能更為適合。
一種方式是使用緩存技術。Rails V2.1 內置了簡單的緩存訪問。使用 Rails.cache.read、 Rails.cache.write 及相關方法，可以輕松創建自己的簡單緩存機制，并且后端可以是一個簡單的內存后端、一個基于文件的后端或一個分布式緩存服務器。在 參考資料 部分可以找到有關 Rails 內置緩存支持的更多信息。但您無需創建自己的緩存解決方案；您可以使用一個預置的 Rails 插件，比如 Nick Kallen 的 cache money 插件。這個插件提供了 write-through 緩存并以 Twitter 上使用的代碼為基礎。更多信息參見 參考資料。
當然，并不是所有的 Rails 問題都與查詢的數量有關。
Rails 分組和聚合計算
您可能遇到的一個問題是在 Ruby 所做的工作本應由數據庫完成。這考驗了 Ruby 的強大程度。很難想象在沒有任何重大激勵的情況下人們會自愿在 C 中重新實現其數據庫代碼的各個部分，但很容易在 Rails 內對 ActiveRecord 對象組進行類似的計算。但是，Ruby 總是要比數據庫代碼慢。所以請不要使用純 Ruby 的方式執行計算，如清單 10 所示。
清單 10. 執行分組計算的不正確方式
|
1
2
|
all_ages = Person.find(:all).group_by(&:age).keys.uniqoldest_age = Person.find(:all).max |
相反，Rails 提供了一系列的分組和聚合函數?？梢韵袂鍐?11 所示的那樣使用它們。
清單 11. 執行分組計算的正確方式
|
1
2
|
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 的例子
|
1
2
3
4
5
6
7
8
9
10
11
12
|
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 的輸出
|
1
2
|
Programmer, avg. age: 18.010, avg. accidents: 9System Administrator, avg. age: 22.720, avg. accidents: 8 |
當然，這是最簡單的例子。您可以自己想象一下如何能將此例中的 SQL 擴展成一個有些復雜性的 SQL 語句。您還可以使用 ActiveRecord::Base.connection.execute 方法運行其他類型的 SQL 語句，比如 ALTER TABLE 語句，如清單 14 所示。
清單 14. 用 ActiveRecord 定制非查找型 SQL
|
1
|
ActiveRecord::Base.connection.execute "ALTER TABLE some_table CHANGE COLUMN..." |
大多數的模式操作，比如添加和刪除列，都可以使用 Rails 的內置方法完成。但如果需要，也可以使用執行任意 SQL 代碼的能力。
結束語
與所有的框架一樣，如果不多加小心和注意，Ruby on Rails 也會遭遇性能問題。所幸的是，監控和修復這些問題的技術相對簡單且易學，而且即便是復雜的問題，只要有耐心并對性能問題的源頭有所了解，也是可以解決的。
