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

原文鏈接: http:///articles/2006/04/03/the-adventures-of-scaling-stage-4

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

第四篇 速度快和穩(wěn)定

在2005年的11月至2006年的3月，許多優(yōu)化的工作都在這期間完成。這里面不少工 作都不得不變成了配置的一部分（比如第三篇提到的請求分發(fā)的監(jiān)控腳本）。最終經(jīng)過了幾周的運行，這個網(wǎng)站被證明是穩(wěn)定且速度快的。另外，我們也已經(jīng)能完成 一點從用戶和社區(qū)運營人員那里的需求。

完成過程中的閃光點

二月份，一些小的調(diào)整讓系統(tǒng)性能變得更好。

第一，當用戶編寫個人消息和在論壇發(fā)帖時，我們利用AJAX來對其內(nèi)容進行預覽。雖然這不是性能的殺手，但把這因素剔除來減輕壓力是有意思的。呃，在AOL瀏覽器中prototype會崩潰。

另外，將作為lighttpd守護進程對待。這樣崩潰的現(xiàn)象在1.4.8及以后的版本就很少出現(xiàn)了，但仍然需要監(jiān)控進程的情況。要知道如果lighttpd down了整個網(wǎng)站就down了。所以得看好它。（譯者評：這里可能會出現(xiàn)單點失敗的情況，clear & dirty）

將lighttpd作為daemontools 來跑是非常簡單的。簡單配置以后（具體配置這些寫得很清楚 http://www./daemontools.html）你在ROR的service樹下面用一行腳本來用damontools 配置lighttpd服務。你會知道并且愛上Rails最初的script/server。

#!/bin/sh

/usr/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf

這樣就啟動好就運行了。你可以通過lighttpd的配置來簡單的設置一下，發(fā)送 lighttpd的進程ID或這信號SIGINT到你后臺的監(jiān)控中。然后需要注意的是如果你的網(wǎng)站流量非常大就需要把那些不能再完成了服務請求通過 SIGKILL殺死。新發(fā)布的lighttpd1.4.11分發(fā)請求時候的僵死越來越少了，似乎這種情況完全沒了。但我們將繼續(xù)通過腳本監(jiān)控它。

到此是這一些列文章的結束了?，F(xiàn)在服務器每天支撐1.2M的PV（100GB的流量）。

總結以及以后的計劃

以下是這四個月被證明是非常有用的優(yōu)化手段：

系統(tǒng)優(yōu)化：

>使用Linux 2.6代替2.4

>使用自己編譯的Ruby 1.8.4

>使用Mysql官方的二進制版本

>使用lighttpd 1.4.11代替以前的

>使用memcache-client代替Ruby-MemCache

>使用了更少數(shù)量的dispatchers

>并且監(jiān)控你的dispathchers

代碼優(yōu)化：

>避免使用ROR的組建 components

>用memcached儲存費時的計算

>用memcached來存儲session

>如果你的站點很受歡迎就不要使用live-previews

>使用異常通知exception notification來捕捉可能的異常

另外不要完全相信這些總結。優(yōu)化是一個發(fā)展中的東西。

你需要一直對網(wǎng)站進行監(jiān)控，包括你的服務器和所有相關的軟件。

強烈建議不僅僅只監(jiān)控服務是否起來了，還好監(jiān)控服務器的壓力，響應時間等等。用Nagios和Cacti結合起來做這些工作被我們證明是很有用的。

提 醒注意的是，需要讀讀所有你使用的軟件包的改變?nèi)罩荆纯葱碌陌姹局薪鉀Q了什么已經(jīng)存在的問題，可能產(chǎn)生哪些新問題。不需要強制升級所有的更新，但對你正 困擾的問題在新版本中別解決了，你就一定要升了。你可以在測試環(huán)境中進行測試，減少當機時間，避免升級帶來的潛在問題。

請留心你網(wǎng)站代碼的變化。一般來說，應該多想想我要做什么。一個像Rails這樣聰明的框架會讓你有機會去思考，而不是每天寫些重復性的代碼。要聰明的使用時間。

一條SQL語句或單個循環(huán)可能在你開發(fā)用的筆記本上跑的很快，但是在產(chǎn)品環(huán)境中同時并發(fā)執(zhí)行成百上千次或產(chǎn)品中數(shù)據(jù)量比較大都有可能導致網(wǎng)站變慢。

性能調(diào)優(yōu)準則
總的來說，不太容易把網(wǎng)站的性能調(diào)節(jié)好。
一種方式是讓網(wǎng)站處于非生產(chǎn)狀態(tài)，也就是測試狀態(tài)，自己產(chǎn)生一些流量來測試，這樣的流量不同于真實的用戶產(chǎn)生的流量。這樣模擬的網(wǎng)站數(shù)據(jù)集也不同于線上的正式產(chǎn)品。這種情況下所有的調(diào)優(yōu)結果都要根據(jù)線上真實網(wǎng)站的情況進行一下轉換。
另 一種方式是對線上實際網(wǎng)站逐步地進行性能調(diào)優(yōu)。這樣有許多好處，你有真實的用戶在使用你的功能，使用你的系統(tǒng)，正如數(shù)據(jù)一樣所有這些都是真實的，比測試環(huán) 境有價值的多。但這種方式主要問題是，如果你的網(wǎng)站訪問量特別大，系統(tǒng)的日志production.log將會大量快速的被寫到硬盤上，這樣你就很難找到 問題。如果做日志的分離，將實際的日志相互關聯(lián)起來也不太容易。那么將日志重定向成系統(tǒng)日志Syslog（通過 SysLogger，在Rails Analyzer Tools包里面），它能將每個日志同一個線程ID關系，這樣就非常方便了。

寫大文件的日志意味這你整個系統(tǒng)的IO補償糟糕，如果你在產(chǎn)品環(huán)境中不要寫太多太詳細的日志，系統(tǒng)將會比你測試的結果跑得好得多。
哦，當網(wǎng)站調(diào)優(yōu)時，拆分用戶將會有比較好的效果，但更重要是的要不斷聽聲網(wǎng)站的使用體驗。

使用過的工具：
將前面提到的Rails Analyzer Tools 包放在手邊，這些工具在類UNIX系統(tǒng)里面非常管用。你還需要會幾個命令，cat,tail,grep,awk,ps,netstat。另外，安裝一下 ngrep和tcpdump來debug網(wǎng)絡流量，還可以用mytop來查看Mysql線程列表。

把這些都準備好需要一些時間、耐心和知識，也偶爾需要Google搜索一下。

將來還要處理的事情

隨著memcache-client庫的發(fā)布，Robot Coop公司又發(fā)布了另一個小的庫，名字叫做cached_model ，這是基于memcached用于減輕數(shù)據(jù)庫重復查詢，原理就是在查詢之前通過子類Active::Base來檢查memcached中的內(nèi)容。

我在1.0版本它出現(xiàn)的時候，看過一下，覺得還是很有發(fā)展的。那個時候它不能很好的集成，經(jīng)常胡亂拋錯。由于當時我們忙于調(diào)試其它的問題，就沒有仔 細地去 解決這些問題。在此期間，cached_model版本升級到了1.1.0，也修復了多個bug。這個東西也將包括與我們將來優(yōu)化的路線圖當中了。

在第三篇的時候我們碰到了一個“分發(fā)請求僵住”的問題，我們將回來再看看FastCGI ，更通常的辦法是用lighttpd也支持的SCGI。

有Zed Shaw發(fā)布了新的軟件Mongrel 已經(jīng)開始出售了。它作為“比WEBrick”更好的應用服務器，將純HTTP放到FastCGI中，非常值得多看看。在讀者評論中

有人說早期Dan Kubb提到用Canditional GET ,它的潛在好處是在緩存頁面不變時它可以用瀏覽器來緩存頁面。我只是簡單地看了一下它的標題，Rails插件看上去還不錯，很容易集成進來。

有個比較大的變化，盡管我曾經(jīng)提倡使用Mysql的全文檢索，但現(xiàn)在我正在基于Rails的一個搜索插件工作，它很容易無縫滴集成到Hyper Estraier 搜索引擎中。如果它跑的很好（性能好和數(shù)據(jù)保護），我們將丟掉全文檢索，弄一個純InnoDB的數(shù)據(jù)庫配置，并且向鎖表和非事務的測試說再見了，同時這樣 也不能使用ROR的schema.rb了。

說道這里，我們升級到了了最近的Rails1.1。盡管這次升級對于性能并沒有太大的必要，但是它有另外受歡迎的地方，它使得我們代碼變得漂亮簡介了。

謝謝看過這一系列文章的人們。我真誠的希望我對我們案例的詳細描述能夠避免再去做我們已經(jīng)做好了的一些研究和調(diào)試工作。如果你需要任何幫助，只要記下我的email,通過聯(lián)系limited overload我可以作為咨詢顧問來幫助你。

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

原文鏈接: http:///articles/2006/04/03/the-adventures-of-scaling-stage-4

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

第四篇 速度快和穩(wěn)定

在2005年的11月至2006年的3月，許多優(yōu)化的工作都在這期間完成。這里面不少工 作都不得不變成了配置的一部分（比如第三篇提到的請求分發(fā)的監(jiān)控腳本）。最終經(jīng)過了幾周的運行，這個網(wǎng)站被證明是穩(wěn)定且速度快的。另外，我們也已經(jīng)能完成 一點從用戶和社區(qū)運營人員那里的需求。

完成過程中的閃光點

二月份，一些小的調(diào)整讓系統(tǒng)性能變得更好。

第一，當用戶編寫個人消息和在論壇發(fā)帖時，我們利用AJAX來對其內(nèi)容進行預覽。雖然這不是性能的殺手，但把這因素剔除來減輕壓力是有意思的。呃，在AOL瀏覽器中prototype會崩潰。

另外，將作為lighttpd守護進程對待。這樣崩潰的現(xiàn)象在1.4.8及以后的版本就很少出現(xiàn)了，但仍然需要監(jiān)控進程的情況。要知道如果lighttpd down了整個網(wǎng)站就down了。所以得看好它。（譯者評：這里可能會出現(xiàn)單點失敗的情況，clear & dirty）

將lighttpd作為daemontools 來跑是非常簡單的。簡單配置以后（具體配置這些寫得很清楚 http://www./daemontools.html）你在ROR的service樹下面用一行腳本來用damontools 配置lighttpd服務。你會知道并且愛上Rails最初的script/server。

#!/bin/sh

/usr/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf

這樣就啟動好就運行了。你可以通過lighttpd的配置來簡單的設置一下，發(fā)送 lighttpd的進程ID或這信號SIGINT到你后臺的監(jiān)控中。然后需要注意的是如果你的網(wǎng)站流量非常大就需要把那些不能再完成了服務請求通過 SIGKILL殺死。新發(fā)布的lighttpd1.4.11分發(fā)請求時候的僵死越來越少了，似乎這種情況完全沒了。但我們將繼續(xù)通過腳本監(jiān)控它。

到此是這一些列文章的結束了?，F(xiàn)在服務器每天支撐1.2M的PV（100GB的流量）。

總結以及以后的計劃

以下是這四個月被證明是非常有用的優(yōu)化手段：

系統(tǒng)優(yōu)化：

>使用Linux 2.6代替2.4

>使用自己編譯的Ruby 1.8.4

>使用Mysql官方的二進制版本

>使用lighttpd 1.4.11代替以前的

>使用memcache-client代替Ruby-MemCache

>使用了更少數(shù)量的dispatchers

>并且監(jiān)控你的dispathchers

代碼優(yōu)化：

>避免使用ROR的組建 components

>用memcached儲存費時的計算

>用memcached來存儲session

>如果你的站點很受歡迎就不要使用live-previews

>使用異常通知exception notification來捕捉可能的異常

另外不要完全相信這些總結。優(yōu)化是一個發(fā)展中的東西。

你需要一直對網(wǎng)站進行監(jiān)控，包括你的服務器和所有相關的軟件。

強烈建議不僅僅只監(jiān)控服務是否起來了，還好監(jiān)控服務器的壓力，響應時間等等。用Nagios和Cacti結合起來做這些工作被我們證明是很有用的。

提 醒注意的是，需要讀讀所有你使用的軟件包的改變?nèi)罩荆纯葱碌陌姹局薪鉀Q了什么已經(jīng)存在的問題，可能產(chǎn)生哪些新問題。不需要強制升級所有的更新，但對你正 困擾的問題在新版本中別解決了，你就一定要升了。你可以在測試環(huán)境中進行測試，減少當機時間，避免升級帶來的潛在問題。

請留心你網(wǎng)站代碼的變化。一般來說，應該多想想我要做什么。一個像Rails這樣聰明的框架會讓你有機會去思考，而不是每天寫些重復性的代碼。要聰明的使用時間。

一條SQL語句或單個循環(huán)可能在你開發(fā)用的筆記本上跑的很快，但是在產(chǎn)品環(huán)境中同時并發(fā)執(zhí)行成百上千次或產(chǎn)品中數(shù)據(jù)量比較大都有可能導致網(wǎng)站變慢。

性能調(diào)優(yōu)準則
總的來說，不太容易把網(wǎng)站的性能調(diào)節(jié)好。
一種方式是讓網(wǎng)站處于非生產(chǎn)狀態(tài)，也就是測試狀態(tài)，自己產(chǎn)生一些流量來測試，這樣的流量不同于真實的用戶產(chǎn)生的流量。這樣模擬的網(wǎng)站數(shù)據(jù)集也不同于線上的正式產(chǎn)品。這種情況下所有的調(diào)優(yōu)結果都要根據(jù)線上真實網(wǎng)站的情況進行一下轉換。
另 一種方式是對線上實際網(wǎng)站逐步地進行性能調(diào)優(yōu)。這樣有許多好處，你有真實的用戶在使用你的功能，使用你的系統(tǒng)，正如數(shù)據(jù)一樣所有這些都是真實的，比測試環(huán) 境有價值的多。但這種方式主要問題是，如果你的網(wǎng)站訪問量特別大，系統(tǒng)的日志production.log將會大量快速的被寫到硬盤上，這樣你就很難找到 問題。如果做日志的分離，將實際的日志相互關聯(lián)起來也不太容易。那么將日志重定向成系統(tǒng)日志Syslog（通過 SysLogger，在Rails Analyzer Tools包里面），它能將每個日志同一個線程ID關系，這樣就非常方便了。

寫大文件的日志意味這你整個系統(tǒng)的IO補償糟糕，如果你在產(chǎn)品環(huán)境中不要寫太多太詳細的日志，系統(tǒng)將會比你測試的結果跑得好得多。
哦，當網(wǎng)站調(diào)優(yōu)時，拆分用戶將會有比較好的效果，但更重要是的要不斷聽聲網(wǎng)站的使用體驗。

使用過的工具：
將前面提到的Rails Analyzer Tools 包放在手邊，這些工具在類UNIX系統(tǒng)里面非常管用。你還需要會幾個命令，cat,tail,grep,awk,ps,netstat。另外，安裝一下 ngrep和tcpdump來debug網(wǎng)絡流量，還可以用mytop來查看Mysql線程列表。

把這些都準備好需要一些時間、耐心和知識，也偶爾需要Google搜索一下。

將來還要處理的事情

隨著memcache-client庫的發(fā)布，Robot Coop公司又發(fā)布了另一個小的庫，名字叫做cached_model ，這是基于memcached用于減輕數(shù)據(jù)庫重復查詢，原理就是在查詢之前通過子類Active::Base來檢查memcached中的內(nèi)容。

我在1.0版本它出現(xiàn)的時候，看過一下，覺得還是很有發(fā)展的。那個時候它不能很好的集成，經(jīng)常胡亂拋錯。由于當時我們忙于調(diào)試其它的問題，就沒有仔 細地去 解決這些問題。在此期間，cached_model版本升級到了1.1.0，也修復了多個bug。這個東西也將包括與我們將來優(yōu)化的路線圖當中了。

在第三篇的時候我們碰到了一個“分發(fā)請求僵住”的問題，我們將回來再看看FastCGI ，更通常的辦法是用lighttpd也支持的SCGI。

有Zed Shaw發(fā)布了新的軟件Mongrel 已經(jīng)開始出售了。它作為“比WEBrick”更好的應用服務器，將純HTTP放到FastCGI中，非常值得多看看。在讀者評論中

有人說早期Dan Kubb提到用Canditional GET ,它的潛在好處是在緩存頁面不變時它可以用瀏覽器來緩存頁面。我只是簡單地看了一下它的標題，Rails插件看上去還不錯，很容易集成進來。

有個比較大的變化，盡管我曾經(jīng)提倡使用Mysql的全文檢索，但現(xiàn)在我正在基于Rails的一個搜索插件工作，它很容易無縫滴集成到Hyper Estraier 搜索引擎中。如果它跑的很好（性能好和數(shù)據(jù)保護），我們將丟掉全文檢索，弄一個純InnoDB的數(shù)據(jù)庫配置，并且向鎖表和非事務的測試說再見了，同時這樣 也不能使用ROR的schema.rb了。

說道這里，我們升級到了了最近的Rails1.1。盡管這次升級對于性能并沒有太大的必要，但是它有另外受歡迎的地方，它使得我們代碼變得漂亮簡介了。

謝謝看過這一系列文章的人們。我真誠的希望我對我們案例的詳細描述能夠避免再去做我們已經(jīng)做好了的一些研究和調(diào)試工作。如果你需要任何幫助，只要記下我的email,通過聯(lián)系limited overload我可以作為咨詢顧問來幫助你。