Ruby On Rails 性能提升

1 Introduction簡介

大家總是說 Rails 好慢啊，這差不多已經成爲 Ruby and Rails 社區裏的一個老生常談的問題了。然而實際上這個說法並不正確。只要正確使用 Rails，把你的應用運行速度提升 10 倍並不困難。那麼如何優化你的應用呢，我們來了解下面的內容。

1.1 優化一個 Rails app 的步驟

導致你的 Rails 應用變慢無非以下兩個原因：

1. 在不應該將 Ruby and Rails 作爲首選的地方使用 Ruby and Rails。（用 Ruby and Rails 做了不擅長做的工作）

2. 過度的消耗內存導致需要利用大量的時間進行垃圾回收。

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