如何提高 Ruby On Rails 性能
大家總是說 Rails 好慢啊，這差不多已經成為 Ruby and Rails 社區里的一個老生常談的問題了。然而實際上這個說法并不正確。只要正確使用 Rails，把你的應用運行速度提升 10 倍并不困難。那么如何優化你的應用呢，我們來了解下面的內容。
1.1 優化一個 Rails app 的步驟
導致你的 Rails 應用變慢無非以下兩個原因：
- 在不應該將 Ruby and Rails 作為首選的地方使用 Ruby and Rails。（用 Ruby and Rails 做了不擅長做的工作）
- 過度的消耗內存導致需要利用大量的時間進行垃圾回收。
Rails 是個令人愉快的框架，而且 Ruby 也是一個簡潔而優雅的語言。但是如果它被濫用，那會相當的影響性能。有很多工作并不適合用 Ruby and Rails，你最好使用其它的工具，比如，數據庫在大數據處理上優勢明顯，R 語言特別適合做統計學相關的工作。
內存問題是導致諸多 Ruby 應用變慢的首要原因。Rails 性能優化的 80-20 法則是這樣的：80% 的提速是源自于對內存的優化，剩下的 20% 屬于其它因素。為什么內存消耗如此重要呢？因為你分配的內存越多，Ruby GC（Ruby 的垃圾回收機制）需要做的工作也就越多。Rails 就已經占用了很大的內存了，而且平均每個應用剛剛啟動后都要占用將近 100M 的內存。如果你不注意內存的控制，你的程序內存增長超過 1G 是很有可能的。需要回收這么多的內存，難怪程序執行的大部分時間都被 GC 占用了。
2 我們如何使一個 Rails 應用運行更快?
有三種方法可以讓你的應用更快：擴容、緩存和代碼優化。
擴容在如今很容易實現。Heroku 基本上就是為你做這個的，而 Hirefire 則讓這一過程更加的自動化。你可以在這個了解到更多有關自動擴容的內容。其它的托管環境提供了類似的解決方案。總之，可以的話你用它就是了。但是請牢記擴容并不是一顆改善性能的銀彈。如果你的應用只需在 5 分鐘內響應一個請求，擴容就沒有什么用。還有就是用 Heroku + Hirefire 幾乎很容易導致你的銀行賬戶透支。我已經見識過 Hirefire 把我一個應用的擴容至 36 個實體，讓我為此支付了 $3100。我立馬就手動吧實例減容到了 2 個, 并且對代碼進行了優化.
Rails 緩存也很容易實施。Rails 4 中的塊緩存非常不錯。Rails 文檔 是有關緩存知識的優秀資料。另外還有一篇 Cheyne Wallace 有關 Rails 性能的文章 也值得一讀。如今設置 Memcached 也簡單。不過同擴容相比，緩存并不能成為性能問題的終極解決方案。如果你的代碼無法理想的運行，那么你將發現自己會把越來越多的資源耗費在緩存上，直到緩存再也不能帶來速度的提升。
讓你的 Rails 應用更快的唯一可靠的方式就是代碼優化。在 Rails 的場景中這就是內存優化。而理所當然的是，如果你接受了我的建議，并且避免把 Rails 用于它的設計能力范圍之外，你就會有更少的代碼要優化。
2.1 避免內存密集型Rails特性
Rails 一些特性花費很多內存導致額外的垃圾收集。列表如下。
2.1.1 序列化程序
序列化程序是從數據庫讀取的字符串表現為 Ruby 數據類型的實用方法。
class Smth < ActiveRecord::Base
serialize :data, JSON
end
Smth.find(...).data
Smth.find(...).data = { ... }
But convenience comes with 3x memory overhead. If you store 100M in data column, expect to allocate 300M just to read it from the database.
它要消耗更多的內存去有效的序列化，你自己看：
class Smth < ActiveRecord::Base
def data
JSON.parse(read_attribute(:data))
end
def data=(value)
write_attribute(:data, value.to_json)
end
end
這將只要 2 倍的內存開銷。有些人，包括我自己，看到 Rails 的 JSON 序列化程序內存泄漏，大約每個請求 10% 的數據量。我不明白這背后的原因。我也不知道是否有一個可復制的情況。如果你有經驗，或者知道怎么減少內存，請告訴我。
2.1.2 活動記錄
很容易與 ActiveRecord 操縱數據。但是 ActiveRecord 本質是包裝了你的數據。如果你有 1g 的表數據，ActiveRecord 表示將要花費 2g，在某些情況下更多。是的，90% 的情況，你獲得了額外的便利。但是有的時候你并不需要，比如，批量更新可以減少 ActiveRecord 開銷。下面的代碼，即不會實例化任何模型，也不會運行驗證和回調。
Book.where('title LIKE ?', '%Rails%').update_all(author: 'David')
后面的場景它只是執行 SQL 更新語句。
update books
set author = 'David'
where title LIKE '%Rails%'
Another example is iteration over a large dataset. Sometimes you need only the data. No typecasting, no updates. This snippet just runs the query and avoids ActiveRecord altogether:
result = ActiveRecord::Base.execute 'select * from books'
result.each do |row|
# do something with row.values_at('col1', 'col2')
end
2.1.3 字符串回調
Rails 回調像之前/之后的保存，之前/之后的動作，以及大量的使用。但是你寫的這種方式可能影響你的性能。這里有 3 種方式你可以寫，比如：在保存之前回調：
before_save :update_status before_save do |model| model.update_status end before_save “self.update_status”
前兩種方式能夠很好的運行，但是第三種不可以。為什么呢？因為執行 Rails 回調需要存儲執行上下文（變量，常量，全局實例等等）就是在回調的時候。如果你的應用很大，你最終在內存里復制了大量的數據。因為回調在任何時候都可以執行，內存在你程序結束之前不可以回收。
有象征，回調在每個請求為我節省了 0.6 秒。
2.2 寫更少的 Ruby
這是我最喜歡的一步。我的大學計算機科學類教授喜歡說，最好的代碼是不存在的。有時候做好手頭的任務需要其它的工具。最常用的是數據庫。為什么呢？因為 Ruby 不善于處理大數據集。非常非常的糟糕。記住，Ruby 占用非常大的內存。所以舉個例子，處理 1G 的數據你可能需要 3G 的或者更多的內存。它將要花費幾十秒的時間去垃圾回收這 3G。好的數據庫可以一秒處理這些數據。讓我來舉一些例子。
2.2.1 屬性預加載
有時候反規范化模型的屬性從另外一個數據庫獲取。比如，想象我們正在構建一個 TODO 列表，包括任務。每個任務可以有一個或者幾個標簽標記。規范化數據模型是這樣的：
Tasks id name Tags id name Tasks_Tags tag_id task_id
加載任務以及它們的 Rails 標簽，你會這樣做：
tasks = Task.find(:all, :include => :tags)
> 0.058 sec
這段代碼有問題，它為每個標簽創建了對象，花費很多內存。可選擇的解決方案，將標簽在數據庫預加載。
tasks = Task.select <<-END
*,
array(
select tags.name from tags inner join tasks_tags on (tags.id = tasks_tags.tag_id)
where tasks_tags.task_id=tasks.id
) as tag_names
END
> 0.018 sec
這只需要內存存儲額外一列，有一個數組標簽。難怪快 3 倍。
2.2.2 數據集合
我所說的數據集合任何代碼去總結或者分析數據。這些操作可以簡單的總結，或者一些更復雜的。以小組排名為例。假設我們有一個員工，部門，工資的數據集，我們要計算員工的工資在一個部門的排名。
SELECT * FROM empsalary; depname | empno | salary -----------+-------+------- develop | 6 | 6000 develop | 7 | 4500 develop | 5 | 4200 personnel | 2 | 3900 personnel | 4 | 3500 sales | 1 | 5000 sales | 3 | 4800
你可以用 Ruby 計算排名：
salaries = Empsalary.all
salaries.sort_by! { |s| [s.depname, s.salary] }
key, counter = nil, nil
salaries.each do |s|
if s.depname != key
key, counter = s.depname, 0
end
counter += 1
s.rank = counter
end
Empsalary 表里 100K 的數據程序在 4.02 秒內完成。替代 Postgres 查詢，使用 window 函數做同樣的工作在 1.1 秒內超過 4 倍。
SELECT depname, empno, salary, rank() OVER (PARTITION BY depname ORDER BY salary DESC) FROM empsalary; depname | empno | salary | rank -----------+-------+--------+------ develop | 6 | 6000 | 1 develop | 7 | 4500 | 2 develop | 5 | 4200 | 3 personnel | 2 | 3900 | 1 personnel | 4 | 3500 | 2 sales | 1 | 5000 | 1 sales | 3 | 4800 | 2
4 倍加速已經令人印象深刻，有時候你得到更多，到 20 倍。從我自己經驗舉個例子。我有一個三維 OLAP 多維數據集與 600k 數據行。我的程序做了切片和聚合。在 Ruby 中，它花費了 1G 的內存大約 90 秒完成。等價的 SQL 查詢在 5 內完成。
2.3 優化 Unicorn
如果你正在使用Unicorn，那么以下的優化技巧將會適用。Unicorn 是 Rails 框架中最快的 web 服務器。但是你仍然可以讓它更運行得快一點。
2.3.1 預載入 App 應用
Unicorn 可以在創建新的 worker 進程前，預載入 Rails 應用。這樣有兩個好處。第一，主線程可以通過寫入時復制的友好GC機制(Ruby 2.0以上)，共享內存的數據。操作系統會透明的復制這些數據，以防被worker修改。第二，預載入減少了worker進程啟動的時間。Rails worker進程重啟是很常見的（稍后將進一步闡述），所以worker重啟的速度越快，我們就可以得到更好的性能。
若需要開啟應用的預載入，只需要在unicorn的配置文件中添加一行：
preload_app true
2.3.2 在 Request 請求間的 GC
請謹記，GC 的處理時間最大會占到應用時間的50%。這個還不是唯一的問題。GC 通常是不可預知的，并且會在你不想它運行的時候觸發運行。那么，你該怎么處理？
首先我們會想到，如果完全禁用 GC 會怎么樣？這個似乎是個很糟糕的想法。你的應用很可能很快就占滿 1G 的內存，而你還未能及時發現。如果你服務器還同時運行著幾個 worker，那么你的應用將很快會出現內存不足，即使你的應用是在自托管的服務器。更不用說只有 512M 內存限制的 Heroku。
其實我們有更好的辦法。那么如果我們無法回避GC，我們可以嘗試讓GC運行的時間點盡量的確定，并且在閑時運行。例如，在兩個request之間，運行GC。這個很容易通過配置Unicorn實現。
對于Ruby 2.1以前的版本，有一個unicorn模塊叫做OobGC:
require 'unicorn/oob_gc'
use(Unicorn::OobGC, 1) # "1" 表示"強制GC在1個request后運行"
對于Ruby 2.1及以后的版本，最好使用gctools(https://github.com/tmm1/gctools):
require 'gctools/oobgc' use(GC::OOB::UnicornMiddleware)
但在request之間運行GC也有一些注意事項。最重要的是，這種優化技術是可感知的。也就是說，用戶會明顯感覺到性能的提升。但是服務器需要做更多的工作。不同于在需要時才運行GC，這種技術需要服務器頻繁的運行GC. 所以，你要確定你的服務器有足夠的資源來運行GC，并且在其他worker正在運行GC的過程中，有足夠的worker來處理用戶的請求。
2.4 有限的增長
我已經給你展示了一些應用會占用1G內存的例子。如果你的內存是足夠的，那么占用這么一大塊內存并不是個大問題。但是Ruby可能不會把這塊內存返還給操作系統。接下來讓我來闡述一下為什么。
Ruby通過兩個堆來分配內存。所有Ruby的對象在存儲在Ruby自己的堆當中。每個對象占用40字節（64位操作系統中）。當對象需要更多內存的時候，它就會在操作系統的堆中分配內存。當對象被垃圾回收并釋放后，被占用的操作系統中的堆的內存將會返還給操作系統，但是Ruby自有的堆當中占用的內存只會簡單的標記為free可用，并不會返還給操作系統。
這意味著，Ruby的堆只會增加不會減少。想象一下，如果你從數據庫讀取了1百萬行記錄，每行10個列。那么你需要至少分配1千萬個對象來存儲這些數據。通常Ruby worker在啟動后占用100M內存。為了適應這么多數據，worker需要額外增加400M的內存（1千萬個對象，每個對象占用40個字節）。即使這些對象最后被收回，這個worker仍然使用著500M的內存。
這里需要聲明， Ruby GC可以減少這個堆的大小。但是我在實戰中還沒發現有這個功能。因為在生產環境中，觸發堆減少的條件很少會出現。
如果你的worker只能增長，最明顯的解決辦法就是每當它的內存占用太多的時候，就重啟該worker。某些托管的服務會這么做，例如Heroku。讓我們來看看其他方法來實現這個功能。
2.4.1 內部內存控制
Trust in God, but lock your car 相信上帝，但別忘了鎖車。（寓意：大部分外國人都有宗教信仰，相信上帝是萬能的，但是日常生活中，誰能指望上帝能幫助自己呢。信仰是信仰，但是有困難的時候 還是要靠自己。）。有兩個途徑可以讓你的應用實現自我內存限制。我管他們做，Kind（友好）和hard（強制）.
Kind 友好內存限制是在每個請求后強制內存大小。如果worker占用的內存過大，那么該worker就會結束，并且unicorn會創建一個新的worker。這就是為什么我管它做“kind”。它不會導致你的應用中斷。
獲取進程的內存大小，使用 RSS 度量在 Linux 和 MacOS 或者 OS gem 在 windows 上。我來展示下在 Unicorn 配置文件里怎么實現這個限制：
class Unicorn::HttpServer
KIND_MEMORY_LIMIT_RSS = 150 #MB
alias process_client_orig process_client
undef_method :process_client
def process_client(client)
process_client_orig(client)
rss = `ps -o rss= -p #{Process.pid}`.chomp.to_i / 1024
exit if rss > KIND_MEMORY_LIMIT_RSS
end
end
硬盤內存限制是通過詢問操作系統去殺你的工作進程，如果它增長很多。在 Unix 上你可以叫 setrlimit 去設置 RSSx 限制。據我所知，這種只在 Linux 上有效。MacOS 實現被打破了。我會感激任何新的信息。
這個片段來自 Unicorn 硬盤限制的配置文件：
after_fork do |server, worker|
worker.set_memory_limits
end
class Unicorn::Worker
HARD_MEMORY_LIMIT_RSS = 600 #MB
def set_memory_limits
Process.setrlimit(Process::RLIMIT_AS, HARD_MEMORY_LIMIT * 1024 * 1024)
end
end
2.4.2 外部內存控制
自動控制沒有從偶爾的 OMM（內存不足）拯救你。通常你應該設置一些外部工具。在 Heroku 上，沒有必要因為它們有自己的監控。但是如果你是自托管，使用 monit，god 是一個很好的主意，或者其它的監視解決方案。
2.5 優化 Ruby GC
在某些情況下，你可以調整 Ruby GC 來改善其性能。我想說，這些 GC 調優變得越來越不重要，Ruby 2.1 的默認設置，后來已經對大多數人有利。
GC 好的調優你需要知道它是怎么工作的。這是一個獨立的主題，不屬于這編文章。要了解更多，徹底讀讀 Sam Saffron 的 揭秘 Ruby GC 這篇文章。在我即將到來的 Ruby 性能的一書，我挖到更深的 Ruby GC 細節。訂閱這個，當我完成這本書的 beta 版本會給你發送一份郵件。
我的建議是最好不要改變 GC 的設置，除非你明確知道你想要做什么，而且有足夠的理論知識知道如何提高性能。對于使用 Ruby 2.1 或之后的版本的用戶，這點尤為重要。
我知道只有一種場合 GC 優化確實能帶來性能的提升。那就是，當你要一次過載入大量的數據。你可以通過改變如下的環境變量來達到減少GC運行的頻率：RUBY_GC_HEAP_GROWTH_FACTOR，RUBY_GC_MALLOC_LIMIT，RUBY_GC_MALLOC_LIMIT_MAX，RUBY_GC_OLDMALLOC_LIMIT，和 RUBY_GC_OLDMALLOC_LIMIT。
請注意，這些變量只適用于 Ruby 2.1 及之后的版本。對于 2.1 之前的版本，可能缺少某一個變量，或者變量不是使用這個名字。
RUBY_GC_HEAP_GROWTH_FACTOR 默認值 1.8，它用于當 Ruby 的堆沒有足夠的空間來分配內存的時候，每次應該增加多少。當你需要使用大量的對象的時候，你希望堆的內存空間增長的快一點。在這種場合，你需要增加該因子的大小。
內存限制是用于定義當你需要向操作系統的堆申請空間的時候，GC 被觸發的頻率。Ruby 2.1 及之后的版本，默認的限額為：
New generation malloc limit RUBY_GC_MALLOC_LIMIT 16M Maximum new generation malloc limit RUBY_GC_MALLOC_LIMIT_MAX 32M Old generation malloc limit RUBY_GC_OLDMALLOC_LIMIT 16M Maximum old generation malloc limit RUBY_GC_OLDMALLOC_LIMIT_MAX 128M
讓我簡要的說明一下這些值的意義。通過設置以上的值，每次新對象分配 16M 到 32M 之間，并且舊對象每占用 16M 到 128M 之間的時候 (“舊對象” 的意思是，該對象至少被垃圾回收調用過一次)， Ruby 將運行 GC。Ruby 會根據你的內存模式，動態的調整當前的限額值。
所以，當你只有少數幾個對象，卻占用了大量的內存（例如讀取一個很大的文件到字符串對象中），你可以增加該限額，以減少 GC 被觸發的頻率。請記住，要同時增加 4 個限額值，而且最好是該默認值的倍數。
我的建議是可能和其他人的建議不一樣。對我可能合適，但對于你卻未必。這些文章將介紹，哪些對 Twitter 適用，而哪些對 Discourse 適用。
2.6 Profile
有時候，這些建議未必就是通用。你需要弄清楚你的問題。這時候，你就要使用 profiler。Ruby-Prof 是每個 Ruby 用戶都會使用的工具。
想知道更多關于 profiling 的知識, 請閱讀 Chris Heald’s 和我的關于在 Rails 中 使用ruby-prof 的文章。還有一些也許有點過時的關于 memory profiling 的建議.
2.7 編寫性能測試用例
最后，提高 Rails 性能的技巧中，雖然不是最重要的，就是確認應用的性能不會因你修改了代碼而導致性能再次下降。Rails 3.x 有一個附帶了一個 性能測試和 profiling 框架 的功能。對于 Rails 4， 你可以通過 rails-perftest gem 使用相同的框架。
3 總結感言
對于一篇文章中，對于如何提高 Ruby 和 Rails 的性能，要面面俱到，確實不可能。所以，在這之后，我會通過寫一本書來總結我的經驗。如果你覺得我的建議有用，請登記 mailinglist ，當我準備好了該書的預覽版之后，將會第一時間通知你。現在，讓我們一起來動手，讓 Rails 應用跑得更快一些吧！
