Ubuntu ruby解析器應(yīng)用程序的優(yōu)化
想知道到Ubuntu ruby系統(tǒng)的真相么，想知道Ubuntu ruby系統(tǒng)中藏有的內(nèi)在奧義么，只有我來給大家全面講解介紹Ubuntu ruby系統(tǒng)Rails應(yīng)用程序優(yōu)化包括Ubuntu ruby解析器的優(yōu)化，緩存的使用，以及應(yīng)用代碼級別的優(yōu)化。Stefans Kaes曾經(jīng)在Railsconf 2006有一個Rails應(yīng)用程序優(yōu)化的演講，他的演講是極好的Rails性能優(yōu)化指南，可以在這里下載:http://www.javaeye.com/topic/24508。
Rails應(yīng)用程序的優(yōu)化
他還編寫了一個用于Rails性能測試的軟件包RailsBench，大家可以參考。由于Stefans Kaes的代碼優(yōu)化文檔已經(jīng)寫的非常詳細了，因此我就不在一一復(fù)述，只提出幾點對性能影響比較大的方面：
一、Ubuntu ruby解析器的優(yōu)化
Ubuntu ruby解析器性能是很糟糕的，Ubuntu ruby解析器早期的主要用途是取代perl寫批量處理的腳本的，并不是為服務(wù)器應(yīng)用編寫的，因此在內(nèi)存分配策略上非常不適合服務(wù)器應(yīng)用。Stefans Kaes編寫了一個Ubuntu ruby解析器 GC的補丁文件，在railsbench下載包里面提供了。
雖然當前Railsbench提供的GC補丁只有針對Ubuntu ruby解析器 1.8.4和1.8.5版本的，但是在Ubuntu ruby解析器 18,6上面使用1.8.5的GC補丁也完全沒有問題。GC補丁的作用主要是針對Rails應(yīng)用開大了Ubuntu ruby解析器的內(nèi)存堆，可以有效提高內(nèi)存堆的利用率，降低GC的頻率。根據(jù)Stefans Kaes提供的測試數(shù)據(jù)，打補丁并且調(diào)整參數(shù)以后，GC的頻率下降到只有原來的1/10還不到。降低GC頻率盡管并不能夠提高單個請求的執(zhí)行速度，但是可以增加整體應(yīng)用的負載能力。
我們在JavaEye的服務(wù)器上也使用了GC補丁，并且根據(jù)推薦參數(shù)進行了調(diào)整。在使用GC補丁之后，Web服務(wù)器的CPU負載下降了大概15%左右，效果非常顯著。當然開大內(nèi)存堆的代價就是Ubuntu ruby解析器進程會多消耗內(nèi)存，在我們的服務(wù)器上，Ubuntu ruby解析器打補丁之后多消耗了50%左右的物理內(nèi)存。
二、緩存的使用
1、對象緩存
JavaEye上面關(guān)于對象緩存的討論很多，我們也提供了JavaEye這方面很多數(shù)據(jù)，因此不展開了。RoR可以使用兩個對象緩存，一個是CachedModel，類似Hibernate，比較簡單，對Model的CRUD操作自動進行緩存；另外一個是cache_fu，需要自己編碼來添加對象緩存，但提供了更多高級機制，目前我們使用的是cache_fu。在使用對象緩存的情況下，應(yīng)該把查詢方法的:include去掉，避免關(guān)聯(lián)查詢無法利用緩存的現(xiàn)象。
2、查詢緩存
對于統(tǒng)計類耗時查詢，如果不要求實時性，那么可以使用memcache-client將查詢結(jié)果緩存到memcached里面，例如博客排行榜之類。
3、頁面局部緩存
對象緩存和查詢緩存都是降低數(shù)據(jù)庫訪問負載的，但如果RoR的負載很高，那么只能依靠頁面局部緩存了。傳統(tǒng)的互聯(lián)網(wǎng)web1.0網(wǎng)站很流行采用動態(tài)頁面靜態(tài)化技術(shù)來提高網(wǎng)站的負載，但是對于web2.0網(wǎng)站來說，每個頁面都帶有登陸用戶的個人信息，頁面的很多部分需要實時更新.
例如投票，點擊統(tǒng)計，digg，顯示用戶在線狀態(tài)等等，動態(tài)頁面靜態(tài)化非常困難。當然如果你非要采用動態(tài)頁面靜態(tài)化，技術(shù)上也不是實現(xiàn)不了，可以通過AJAX請求來處理靜態(tài)頁面的動態(tài)部分，但是這種解決方案的開發(fā)成本過高，而且性能未必會有明顯的改善，大家看看新浪和搜狐博客就知道這種技術(shù)被應(yīng)用的有多糟糕了。
web2.0網(wǎng)站比較常用使用頁面局部緩存，一種情況是頁面不需要實時更新的，那么只需要設(shè)置一個合理的過期時間就行了，這種情況我們目前使用的比較多；另外一種情況是雖然不需要實時更新，但是會在用戶執(zhí)行某些操作后需要緩存過期，比方說博客個人主頁的很多頁面，這種情況下緩存過期策略會比較復(fù)雜，考慮到合理的開發(fā)成本，我們尚未對這樣的頁面使用局部緩存。
此外，Rails的頁面局部緩存有一個缺點，就是和頁面查詢結(jié)果對應(yīng)的Action當中的查詢語句要放在View里面，否則每次action里面的查詢還是會被執(zhí)行，但是這樣做會破壞程序代碼良好的MVC結(jié)構(gòu)。這種情況下，也可以采用另外一個Cache插件: better rails caching，在緩存頁面的同時可以緩存Action當中的查詢語句。
三、應(yīng)用代碼的優(yōu)化
Stefans Kaes的文檔里面對應(yīng)用代碼的優(yōu)化進行了非常詳細的介紹，因此我這里只提兩個比較重要的注意事項：
1、link_to
Rails的link_to是非常慢的，它的代碼實現(xiàn)過于復(fù)雜，特別是Rails1.2引入了REST以后，大量的命名路由被使用，這些命名路由還需要通過一次method_missing，那就更加緩慢了。因此對于被頻繁使用的內(nèi)部URL地址，一定要自己用字符串拼接方式改寫，可以很明顯提高View的render性能。此外類似的helper還有很多，例如button_tag，image_tag啥啥的，如非必要，盡量不用他的helper
2、正則表達式
Ubuntu ruby解析器的正則表達式也是極慢，例如auto_fix這個helper的正則表達式就比較復(fù)雜，造成的結(jié)果就是一但大量使用auto_fix，View的render就明顯變慢，類似依賴正則表達式進行字符串過濾的helper有很多，如果需要頻繁大量使用，請先自行做benchmark。
【編輯推薦】
