一個RoR的站點性能優(yōu)化的故事(1)

應(yīng)該是去年吧，當時為了慶祝enissue.com開張;朋友Sweater翻譯了這系列文章，站點資料丟失了，從Google search中找到重新貼出.

請所有轉(zhuǎn)載者保留署名.

原文鏈接: http:///2006/3/13/the-adventures-of-scaling-stage-1

中文鏈接: http:///2009/08/01/00/02/一個ror的站點性能優(yōu)化的故事.html

許多大流量的網(wǎng)站都是由Rails支撐的，《WEB開發(fā)之道——應(yīng)用RAILS進行敏捷WEB開發(fā)》(第二版) 這本書對于擴展你的應(yīng)用是非常有幫助的.這個系列的文章是一個實際的例子，例子說明了“如何擴展你的Rail應(yīng)用？”我會講述一下我們在提高應(yīng)用性能時所作的事情。

我們的整個性能調(diào)優(yōu)過程，將分四篇文章來講述，每一篇都是在我們擴展我們網(wǎng)站的一個里程碑。文章計劃在一周內(nèi)全部發(fā)表出來。

實際情況

我們的任務(wù)是重寫全部代碼，這個在線社區(qū)網(wǎng)絡(luò)以前是用php寫的，原來是一個代碼膨脹而且架構(gòu)的非常糟糕！作為一個在線社區(qū)，正如你 知道的一樣，網(wǎng)站包含如下功能：論壇、評論、個人主頁、個人站內(nèi)消息、編輯內(nèi)容等等。另外，在德國的幾個大城市都有當?shù)氐暮献骰锇?，他們? 各個子版塊的重要驅(qū)動力。各地的用戶是在一個統(tǒng)一的單個數(shù)據(jù)集中。

原有代碼大概由5萬行php代碼和另外一個閉源的CMS組成（CMS不計入代碼行數(shù)統(tǒng)計中）組成。這次重寫大概只用了5千行Rails代碼，就實現(xiàn)原來的大部分功能（原來的一些個功能按計劃在這此重寫中被剔除了）。

每天包含大概120萬個動態(tài)頁面，服務(wù)于25個子社區(qū)，每個社區(qū)是用不同的域名，但所有這些都在一個Rails應(yīng)用中。然而，還沒有到今年的二月，我們對系統(tǒng)配置和代碼都做了優(yōu)化，這樣在才能處理如此巨大的流量。

這個網(wǎng)站存在許多動態(tài)頁面和信息，動態(tài)信息是基于用戶設(shè)置或像在線狀態(tài)和相互關(guān)系狀態(tài)。這些都是阻礙我們使用Rails本身提供的非常簡單的頁面緩存或局部緩存。

該應(yīng)用服務(wù)器配置是dual Xeon 3.06GHz, 2GB RAM, SCSI U320 HDDs RAID-1.數(shù)據(jù)庫服務(wù)器dual Xeon 3.06GHz, 4GB RAM, SCSI U320 HDDs RAID-1. 代理服務(wù)器是單臺 P4 3.0GHz, 2GB RAM, SCSI U320 HDDs RAID-1.

在不改變硬件條件的前提下，我想準備通過配置優(yōu)化和修改代碼來提高性能，與此同時還要加上一些新功能。

在11月，我們最高每天能夠支撐75w的PV（大約有60G的流量），到了來年的3月份，我們很輕松的能夠支撐120w的PV（大約有100G的流量），最終性能提升了1.6倍。（譯者評：技術(shù)真的都變成錢了?。。?/p>

高峰時期通大概20M/每秒的數(shù)據(jù)通過代理服務(wù)器的網(wǎng)卡。（譯者評：餓滴神）

well，任何人都不能改變歷史，以下是我們以前的系統(tǒng)配置，也就是上面這個圖中所示的軟件的詳細信息。

我們使用Rails中的 ActiveRecodStore來管理session，用 在數(shù)據(jù)庫服務(wù)器上的token based single-signon 機制和 memcached來在內(nèi)存中存儲大數(shù)據(jù)量的計算。

兩臺數(shù)據(jù)庫服務(wù)器通過master-master的方式相互復制，他們的自增ID是相互間隔的。（譯者評：比如，一臺的ID增長是1、3、5，另一臺是2、4、6）.具體實現(xiàn)參看《mysql手冊》的auto_increment_increment 和 auto_increment_offset.

haproxy 被用于外部的FastCGI 偵聽的負載均衡，以及應(yīng)用服務(wù)器的數(shù)據(jù)庫鏈接通過它分發(fā)到兩臺數(shù)據(jù)庫服務(wù)器上。

以 上基本上是一個總體的介紹，性能的優(yōu)化是非常難的一件事情。基于PHP的老系統(tǒng)處理到90萬PV時就會崩潰（這就是說，只要以前一半的應(yīng)用服務(wù)器就行 了），而新的架構(gòu)在巨大的150萬PV的時候才會崩潰。這里面不存在突然會變成你所想像的那樣好，所有這些變化都在此以前用了無數(shù)的日日夜夜coding 才達到的。

緊急情況設(shè)計
是的，我們曾經(jīng)正在繳費準備飛到巴哈馬群島，并呆在那。

FastCGI 監(jiān)聽數(shù)目作為首要的方法從20下降到了10.說實話，原來系統(tǒng)的設(shè)置根本沒法用.頁面每次從開始load都有延遲，與此同時，對于系統(tǒng)做大可支持的負載的 失望和一些沒有耐心的用戶還會重復load讓事情變得更糟。用新的設(shè)置，這些事情會減少一些，而且快了許多。

過了幾天，在新系統(tǒng)上線后，我們又采用了其它幾個方法來提高性能，并且修復了一些在測試中沒找到的bug.睡覺是多么美好和奢侈的啊。

我們做的幾件重要的事情，使得這次升級更加成功：
>強烈指出haproxy，它仍有另外的變量能更調(diào)整，直接使用它并不會有明顯的效果。所有應(yīng)用服務(wù)器對于Mysql的鏈接都可以在文件中配置成像連接單個Mysql主機。
FastCGI 連接的分發(fā)由lighttpd返回。提示：我們發(fā)現(xiàn)要想請求真正均勻的分配到多臺應(yīng)用服務(wù)器上，你應(yīng)該定制fastcgi。服務(wù)器的端口和IP的配置應(yīng)該如下：

"http-1-01" => ( "host" => "10.10.1.10", "port" => 7000 ),
"http-2-01" => ( "host" => "10.10.1.11", "port" => 7000 ),
"http-3-01" => ( "host" => "10.10.1.12", "port" => 7000 ),
"http-4-01" => ( "host" => "10.10.1.13", "port" => 7000 ),
"http-1-02" => ( "host" => "10.10.1.10", "port" => 7001 ),
"http-2-02" => ( "host" => "10.10.1.11", "port" => 7001 ),
"http-3-02" => ( "host" => "10.10.1.12", "port" => 7001 ),
"http-4-02" => ( "host" => "10.10.1.13", "port" => 7001 ),

>雖然局部緩存被認為對于用戶是不靈活的（數(shù)據(jù)延遲，不再個性化），并且沒有改進，但是還是要使用它。畢竟稍后問題都有反饋。
>停止同時使用兩個memcached主機的想法，由于Ruby-MemCache庫顯然不能很好地處理。實現(xiàn)分布式的方式不是基于一個key，而是隨機。讓我們最頭疼的就是分布式垃圾數(shù)據(jù)的到期問題。
>重構(gòu)了工具條的代碼，原來這段代碼是用Rails中的component，有顯示它是性能殺手。一般可以為每一個sidebar的顯示設(shè)置完整的controller環(huán)境。（具體參見 RailsExpress）
>添加gzip的壓縮作為after_filter(參見Rails 書中的例子)
>用Mysql slow query log參數(shù)來找出速度慢的sql語句，減少表的joins，優(yōu)化索引。（呵呵，這個顯然不是Rails的范圍）

這時候已經(jīng)到了11月，這個時候我們每天可以處理85萬PV，似乎沒做什么事情，你可以說“太簡單了！”

我們新的簡化過的設(shè)計如下：

第二部分將會著重講述性能調(diào)優(yōu)，包括mysql調(diào)優(yōu)小技巧，F(xiàn)astGCI 請求分派調(diào)優(yōu)，和更多的系統(tǒng)優(yōu)化技術(shù)。