一個(gè)RoR的站點(diǎn)性能優(yōu)化的故事(1)

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

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

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

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

許多大流量的網(wǎng)站都是由Rails支撐的，《WEB開(kāi)發(fā)之道——應(yīng)用RAILS進(jìn)行敏捷WEB開(kāi)發(fā)》(第二版) 這本書對(duì)于擴(kuò)展你的應(yīng)用是非常有幫助的.這個(gè)系列的文章是一個(gè)實(shí)際的例子，例子說(shuō)明了“如何擴(kuò)展你的Rail應(yīng)用？”我會(huì)講述一下我們?cè)谔岣邞?yīng)用性能時(shí)所作的事情。

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

實(shí)際情況

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

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

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

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

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

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

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

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

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

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

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

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

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

緊急情況設(shè)計(jì)
是的，我們?cè)?jīng)正在繳費(fèi)準(zhǔn)備飛到巴哈馬群島，并呆在那。

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

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

我們做的幾件重要的事情，使得這次升級(jí)更加成功：
>強(qiáng)烈指出haproxy，它仍有另外的變量能更調(diào)整，直接使用它并不會(huì)有明顯的效果。所有應(yīng)用服務(wù)器對(duì)于Mysql的鏈接都可以在文件中配置成像連接單個(gè)Mysql主機(jī)。
FastCGI 連接的分發(fā)由lighttpd返回。提示：我們發(fā)現(xiàn)要想請(qǐng)求真正均勻的分配到多臺(tái)應(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 ),

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

這時(shí)候已經(jīng)到了11月，這個(gè)時(shí)候我們每天可以處理85萬(wàn)PV，似乎沒(méi)做什么事情，你可以說(shuō)“太簡(jiǎn)單了！”

我們新的簡(jiǎn)化過(guò)的設(shè)計(jì)如下：

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