原文鏈接: http://poocs.net/articles/2006/04/03/the-adventures-of-scaling-stage-4
中文鏈接: http://ityum.net/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)性能變得更好。
第一，當(dāng)用戶編寫個人消息和在論壇發(fā)帖時，我們利用AJAX來對其內(nèi)容進(jìn)行預(yù)覽。雖然這不是性能的殺手，但把這因素剔除來減輕壓力是有意思的。呃，在AOL瀏覽器中prototype會崩潰。
另外，將作為lighttpd守護(hù)進(jìn)程對待。這樣崩潰的現(xiàn)象在1.4.8及以后的版本就很少出現(xiàn)了，但仍然需要監(jiān)控進(jìn)程的情況。要知道如果lighttpd down了整個網(wǎng)站就down了。所以得看好它。（譯者評：這里可能會出現(xiàn)單點失敗的情況，clear & dirty）
將lighttpd作為daemontools 來跑是非常簡單的。簡單配置以后（具體配置這些寫得很清楚 http://www.thedjbway.org/daemontools.html）你在ROR的service樹下面用一行腳本來用damontools 配置lighttpd服務(wù)。你會知道并且愛上Rails最初的script/server。
#!/bin/sh
/usr/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf
這樣就啟動好就運行了。你可以通過lighttpd的配置來簡單的設(shè)置一下，發(fā)送lighttpd的進(jìn)程ID或這信號SIGINT到你后臺的監(jiān)控中。然后需要注意的是如果你的網(wǎng)站流量非常大就需要把那些不能再完成了服務(wù)請求通過SIGKILL殺死。新發(fā)布的lighttpd1.4.11分發(fā)請求時候的僵死越來越少了，似乎這種情況完全沒了。但我們將繼續(xù)通過腳本監(jiān)控它。
到此是這一些列文章的結(jié)束了?，F(xiàn)在服務(wù)器每天支撐1.2M的PV（100GB的流量）。
總結(jié)以及以后的計劃
以下是這四個月被證明是非常有用的優(yōu)化手段：
系統(tǒng)優(yōu)化：
>使用Linux 2.6代替2.4
>使用自己編譯的Ruby 1.8.4
>使用Mysql官方的二進(jìn)制版本
>使用lighttpd 1.4.11代替以前的
>使用memcache-client代替Ruby-MemCache
>使用了更少數(shù)量的dispatchers
>并且監(jiān)控你的dispathchers
代碼優(yōu)化：
>避免使用ROR的組建 components
>用memcached儲存費時的計算
>用memcached來存儲session
>如果你的站點很受歡迎就不要使用live-previews
>使用異常通知exception notification來捕捉可能的異常
另外不要完全相信這些總結(jié)。優(yōu)化是一個發(fā)展中的東西。
你需要一直對網(wǎng)站進(jìn)行監(jiān)控，包括你的服務(wù)器和所有相關(guān)的軟件。
強烈建議不僅僅只監(jiān)控服務(wù)是否起來了，還好監(jiān)控服務(wù)器的壓力，響應(yīng)時間等等。用Nagios和Cacti結(jié)合起來做這些工作被我們證明是很有用的。
提醒注意的是，需要讀讀所有你使用的軟件包的改變?nèi)罩?，看看新的版本中解決了什么已經(jīng)存在的問題，可能產(chǎn)生哪些新問題。不需要強制升級所有的更新，但對你正困擾的問題在新版本中別解決了，你就一定要升了。你可以在測試環(huán)境中進(jìn)行測試，減少當(dāng)機時間，避免升級帶來的潛在問題。
請留心你網(wǎng)站代碼的變化。一般來說，應(yīng)該多想想我要做什么。一個像Rails這樣聰明的框架會讓你有機會去思考，而不是每天寫些重復(fù)性的代碼。要聰明的使用時間。
一條SQL語句或單個循環(huán)可能在你開發(fā)用的筆記本上跑的很快，但是在產(chǎn)品環(huán)境中同時并發(fā)執(zhí)行成百上千次或產(chǎn)品中數(shù)據(jù)量比較大都有可能導(dǎo)致網(wǎng)站變慢。
性能調(diào)優(yōu)準(zhǔn)則
總的來說，不太容易把網(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)結(jié)果都要根據(jù)線上真實網(wǎng)站的情況進(jìn)行一下轉(zhuǎn)換。
另一種方式是對線上實際網(wǎng)站逐步地進(jìn)行性能調(diào)優(yōu)。這樣有許多好處，你有真實的用戶在使用你的功能，使用你的系統(tǒng)，正如數(shù)據(jù)一樣所有這些都是真實的，比測試環(huán)境有價值的多。但這種方式主要問題是，如果你的網(wǎng)站訪問量特別大，系統(tǒng)的日志production.log將會大量快速的被寫到硬盤上，這樣你就很難找到問題。如果做日志的分離，將實際的日志相互關(guān)聯(lián)起來也不太容易。那么將日志重定向成系統(tǒng)日志Syslog（通過 SysLogger，在RailsAnalyzer Tools包里面），它能將每個日志同一個線程ID關(guān)系，這樣就非常方便了。
寫大文件的日志意味這你整個系統(tǒng)的IO補償糟糕，如果你在產(chǎn)品環(huán)境中不要寫太多太詳細(xì)的日志，系統(tǒng)將會比你測試的結(jié)果跑得好得多。
哦，當(dā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)絡(luò)流量，還可以用mytop來查看Mysql線程列表。
把這些都準(zhǔn)備好需要一些時間、耐心和知識，也偶爾需要Google搜索一下。
將來還要處理的事情
隨著memcache-client庫的發(fā)布，Robot Coop公司又發(fā)布了另一個小的庫，名字叫做cached_model，這是基于memcached用于減輕數(shù)據(jù)庫重復(fù)查詢，原理就是在查詢之前通過子類Active::Base來檢查memcached中的內(nèi)容。
我在1.0版本它出現(xiàn)的時候，看過一下，覺得還是很有發(fā)展的。那個時候它不能很好的集成，經(jīng)常胡亂拋錯。由于當(dāng)時我們忙于調(diào)試其它的問題，就沒有仔細(xì)地去解決這些問題。在此期間，cached_model版本升級到了1.1.0，也修復(fù)了多個bug。這個東西也將包括與我們將來優(yōu)化的路線圖當(dāng)中了。
在第三篇的時候我們碰到了一個“分發(fā)請求僵住”的問題，我們將回來再看看FastCGI ，更通常的辦法是用lighttpd也支持的SCGI。
有Zed Shaw發(fā)布了新的軟件Mongrel 已經(jīng)開始出售了。它作為“比WEBrick”更好的應(yīng)用服務(wù)器，將純HTTP放到FastCGI中，非常值得多看看。在讀者評論中
有人說早期Dan Kubb提到用Canditional GET ,它的潛在好處是在緩存頁面不變時它可以用瀏覽器來緩存頁面。我只是簡單地看了一下它的標(biāo)題，Rails插件看上去還不錯，很容易集成進(jìn)來。
有個比較大的變化，盡管我曾經(jīng)提倡使用Mysql的全文檢索，但現(xiàn)在我正在基于Rails的一個搜索插件工作，它很容易無縫滴集成到HyperEstraier搜索引擎中。如果它跑的很好（性能好和數(shù)據(jù)保護(hù)），我們將丟掉全文檢索，弄一個純InnoDB的數(shù)據(jù)庫配置，并且向鎖表和非事務(wù)的測試說再見了，同時這樣也不能使用ROR的schema.rb了。
說道這里，我們升級到了了最近的Rails1.1。盡管這次升級對于性能并沒有太大的必要，但是它有另外受歡迎的地方，它使得我們代碼變得漂亮簡介了。
謝謝看過這一系列文章的人們。我真誠的希望我對我們案例的詳細(xì)描述能夠避免再去做我們已經(jīng)做好了的一些研究和調(diào)試工作。如果你需要任何幫助，只要記下我的email,通過聯(lián)系limited overload我可以作為咨詢顧問來幫助你。
原文鏈接: http://poocs.net/articles/2006/04/03/the-adventures-of-scaling-stage-4
中文鏈接: http://ityum.net/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)性能變得更好。
第一，當(dāng)用戶編寫個人消息和在論壇發(fā)帖時，我們利用AJAX來對其內(nèi)容進(jìn)行預(yù)覽。雖然這不是性能的殺手，但把這因素剔除來減輕壓力是有意思的。呃，在AOL瀏覽器中prototype會崩潰。
另外，將作為lighttpd守護(hù)進(jìn)程對待。這樣崩潰的現(xiàn)象在1.4.8及以后的版本就很少出現(xiàn)了，但仍然需要監(jiān)控進(jìn)程的情況。要知道如果lighttpd down了整個網(wǎng)站就down了。所以得看好它。（譯者評：這里可能會出現(xiàn)單點失敗的情況，clear & dirty）
將lighttpd作為daemontools 來跑是非常簡單的。簡單配置以后（具體配置這些寫得很清楚 http://www.thedjbway.org/daemontools.html）你在ROR的service樹下面用一行腳本來用damontools 配置lighttpd服務(wù)。你會知道并且愛上Rails最初的script/server。
#!/bin/sh
/usr/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf
這樣就啟動好就運行了。你可以通過lighttpd的配置來簡單的設(shè)置一下，發(fā)送lighttpd的進(jìn)程ID或這信號SIGINT到你后臺的監(jiān)控中。然后需要注意的是如果你的網(wǎng)站流量非常大就需要把那些不能再完成了服務(wù)請求通過SIGKILL殺死。新發(fā)布的lighttpd1.4.11分發(fā)請求時候的僵死越來越少了，似乎這種情況完全沒了。但我們將繼續(xù)通過腳本監(jiān)控它。
到此是這一些列文章的結(jié)束了?，F(xiàn)在服務(wù)器每天支撐1.2M的PV（100GB的流量）。
總結(jié)以及以后的計劃
以下是這四個月被證明是非常有用的優(yōu)化手段：
系統(tǒng)優(yōu)化：
>使用Linux 2.6代替2.4
>使用自己編譯的Ruby 1.8.4
>使用Mysql官方的二進(jìn)制版本
>使用lighttpd 1.4.11代替以前的
>使用memcache-client代替Ruby-MemCache
>使用了更少數(shù)量的dispatchers
>并且監(jiān)控你的dispathchers
代碼優(yōu)化：
>避免使用ROR的組建 components
>用memcached儲存費時的計算
>用memcached來存儲session
>如果你的站點很受歡迎就不要使用live-previews
>使用異常通知exception notification來捕捉可能的異常
另外不要完全相信這些總結(jié)。優(yōu)化是一個發(fā)展中的東西。
你需要一直對網(wǎng)站進(jìn)行監(jiān)控，包括你的服務(wù)器和所有相關(guān)的軟件。
強烈建議不僅僅只監(jiān)控服務(wù)是否起來了，還好監(jiān)控服務(wù)器的壓力，響應(yīng)時間等等。用Nagios和Cacti結(jié)合起來做這些工作被我們證明是很有用的。
提醒注意的是，需要讀讀所有你使用的軟件包的改變?nèi)罩?，看看新的版本中解決了什么已經(jīng)存在的問題，可能產(chǎn)生哪些新問題。不需要強制升級所有的更新，但對你正困擾的問題在新版本中別解決了，你就一定要升了。你可以在測試環(huán)境中進(jìn)行測試，減少當(dāng)機時間，避免升級帶來的潛在問題。
請留心你網(wǎng)站代碼的變化。一般來說，應(yīng)該多想想我要做什么。一個像Rails這樣聰明的框架會讓你有機會去思考，而不是每天寫些重復(fù)性的代碼。要聰明的使用時間。
一條SQL語句或單個循環(huán)可能在你開發(fā)用的筆記本上跑的很快，但是在產(chǎn)品環(huán)境中同時并發(fā)執(zhí)行成百上千次或產(chǎn)品中數(shù)據(jù)量比較大都有可能導(dǎo)致網(wǎng)站變慢。
性能調(diào)優(yōu)準(zhǔn)則
總的來說，不太容易把網(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)結(jié)果都要根據(jù)線上真實網(wǎng)站的情況進(jìn)行一下轉(zhuǎn)換。
另一種方式是對線上實際網(wǎng)站逐步地進(jìn)行性能調(diào)優(yōu)。這樣有許多好處，你有真實的用戶在使用你的功能，使用你的系統(tǒng)，正如數(shù)據(jù)一樣所有這些都是真實的，比測試環(huán)境有價值的多。但這種方式主要問題是，如果你的網(wǎng)站訪問量特別大，系統(tǒng)的日志production.log將會大量快速的被寫到硬盤上，這樣你就很難找到問題。如果做日志的分離，將實際的日志相互關(guān)聯(lián)起來也不太容易。那么將日志重定向成系統(tǒng)日志Syslog（通過 SysLogger，在RailsAnalyzer Tools包里面），它能將每個日志同一個線程ID關(guān)系，這樣就非常方便了。
寫大文件的日志意味這你整個系統(tǒng)的IO補償糟糕，如果你在產(chǎn)品環(huán)境中不要寫太多太詳細(xì)的日志，系統(tǒng)將會比你測試的結(jié)果跑得好得多。
哦，當(dā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)絡(luò)流量，還可以用mytop來查看Mysql線程列表。
把這些都準(zhǔn)備好需要一些時間、耐心和知識，也偶爾需要Google搜索一下。
將來還要處理的事情
隨著memcache-client庫的發(fā)布，Robot Coop公司又發(fā)布了另一個小的庫，名字叫做cached_model，這是基于memcached用于減輕數(shù)據(jù)庫重復(fù)查詢，原理就是在查詢之前通過子類Active::Base來檢查memcached中的內(nèi)容。
我在1.0版本它出現(xiàn)的時候，看過一下，覺得還是很有發(fā)展的。那個時候它不能很好的集成，經(jīng)常胡亂拋錯。由于當(dāng)時我們忙于調(diào)試其它的問題，就沒有仔細(xì)地去解決這些問題。在此期間，cached_model版本升級到了1.1.0，也修復(fù)了多個bug。這個東西也將包括與我們將來優(yōu)化的路線圖當(dāng)中了。
在第三篇的時候我們碰到了一個“分發(fā)請求僵住”的問題，我們將回來再看看FastCGI ，更通常的辦法是用lighttpd也支持的SCGI。
有Zed Shaw發(fā)布了新的軟件Mongrel 已經(jīng)開始出售了。它作為“比WEBrick”更好的應(yīng)用服務(wù)器，將純HTTP放到FastCGI中，非常值得多看看。在讀者評論中
有人說早期Dan Kubb提到用Canditional GET ,它的潛在好處是在緩存頁面不變時它可以用瀏覽器來緩存頁面。我只是簡單地看了一下它的標(biāo)題，Rails插件看上去還不錯，很容易集成進(jìn)來。
有個比較大的變化，盡管我曾經(jīng)提倡使用Mysql的全文檢索，但現(xiàn)在我正在基于Rails的一個搜索插件工作，它很容易無縫滴集成到HyperEstraier搜索引擎中。如果它跑的很好（性能好和數(shù)據(jù)保護(hù)），我們將丟掉全文檢索，弄一個純InnoDB的數(shù)據(jù)庫配置，并且向鎖表和非事務(wù)的測試說再見了，同時這樣也不能使用ROR的schema.rb了。
說道這里，我們升級到了了最近的Rails1.1。盡管這次升級對于性能并沒有太大的必要，但是它有另外受歡迎的地方，它使得我們代碼變得漂亮簡介了。
謝謝看過這一系列文章的人們。我真誠的希望我對我們案例的詳細(xì)描述能夠避免再去做我們已經(jīng)做好了的一些研究和調(diào)試工作。如果你需要任何幫助，只要記下我的email,通過聯(lián)系limited overload我可以作為咨詢顧問來幫助你。
