Rails 3.2 效能: 更慢了?

類別: IT
標籤: rails

擁有一個大型程式碼庫意味著我們不能很經常升級Rails的版本(我們平均每兩年一次升級,每次升級需要1-2周的開發時間)。不過每次我們做升級工作的時候,我最先好奇的事情之一是,檢查不同版本之間的效能差異。

就我們之前的升級來說,在從Rails 2.3 到 Rails 3.0的過程中,我記錄下來的平均動作變得要慢2倍,一個動作需要的平均時間由225ms攀升到480ms。幸運的是,在這種情境下我們可以拿出一些技巧(GC調優),這樣我們最終將同樣的動作時間縮減到280ms。即使是實現一些新奇的技巧,這個時間仍然比Rails 2.3要慢約25%,但是我們已經可以接受這個結果了。

當我們最終決定由Rails 3.0升級到3.2,以便與最新的gems相容的時候,由於我們之前的經歷,可想而知我對效能有何等下降是多麼的急切。根據手頭現有數字,看來有必要對此加以理解。這裡是上次我描述到的同一個動作(最常見的動作——顯示一個條目的動作)的不同表現情況,在升級以前的Rails 3.0上:

在升級以前最常見的動作,在3小時的時間視窗中平均需要301ms

這裡是現在的樣子:

升級以後,與上週相同時間段,在3小時的時間視窗中平均需要423ms

與上次不同,3.2的問題在於,我們再也沒有辦法憑空捏造更多的技巧。我們已經升級到最新最偉大的Ruby 2.0版本。在請求期間我們已經禁止了GC(感謝有Passenger!)。我們完成這些升級以後,Rails 3.0的應用速度快了大約25%。但是現在由於Rails 3.2中我們需要承受控制器與檢視渲染的40%效能下降,這些效能提升被遮蔽了,而且在做Ruby優化以前,反而比3.0中的速度還要慢。

總而言之,如果你有基於Rails的大型應用,此刻你可能已經懂得對Rails新版本心存畏懼。我完全理解那些為 Rails LTS交錢的人。(譯註:LTS即 Long Term Support)如果我們不需要與新的gems相容,仍然使用2.3,這將使我們比Rails 3.0速度快100%,相應的比Rails 3.2速度快40%。


新版的Rails 鼓吹各種改進,像“建立單頁web應用的能力”、“更嚴格的預設安全性”以及“改革,簡化”其組成庫。我們看到的最近一次的效能提升,是3.2版本使開發環境的載入加快了(1)。這顯然是一個令人難以置信的提升(使平均的開發頁載入由5秒以上縮減到1-2秒),儘管由於active_reload,我們已經在Rails 3.0有這樣的效能提升。

我覺得在驅動Rails開發的各種要素中,現在效能已經成為最不被關注的一個了,如果真是如此,那麼這是令人相當羞愧的。如果Rails也像它所做的“改革,簡化”一樣,花同等的時間分析/改進效能,很難相信每次版本升級我們會承受40%-100%的效能退化。或許與New Relic的合作可以幫助Rails團隊看到,對那些基於他們的平臺而建立的實際應用來說,他們的決策具有何種現實的影響。如果其他人的經歷與我們相似,那麼可以說這是許多人感受到的許多的痛苦。

我承認我有點不願意寫這篇文章,因為作為一個平臺Rails給了我們太多,而且目前我們的業務太小,還不至於能直接牽涉到Rails的效能改進。但是我們將繼續發表任何我們發現的、明顯的優化策略,發表到這個部落格或者別的什麼地方。

不過我最關心的,同時也是我發表此文的原因是,如果Rails繼續以這樣的幅度降低速度,我不確定是否在4.x 或 5.x系列版本中,是否會有“沒有返回的時間點”,在那時它將慢到我們無法再做任何升級。每次我們追隨的新版本都向著那種可能性邁進了一步,即使我們購買了史上最快的伺服器,並且給編譯器實現了史上最耗心血的優化。

還有人做過由中等規模到大規模webapp的Rails 2 -> 3 -> 4這樣的升級嗎?我非常渴望聽到你的經驗。當Google搜尋“Rails效能”時,只有很少的一點結果,這總是使我想知道其他開發者升級經驗的更多細節。

(1)就像在相容的web伺服器上使用動態流一樣,在某些情況下,新的快取模型也可以提升效能。由於這篇文章的目的我是著眼於“效能”,而效能屬於在伺服器上執行的動態web應用程式範疇,這意味著(我們所關注的是)諸如解釋請求,與資料庫互動,以及呈現響應。

Rails 3.2 效能: 更慢了?原文請看這裡