Ubuntu ror性能優(yōu)化經(jīng)驗與應(yīng)用的部署
特別值得一提的是Ubuntu ror有很多值得學(xué)習(xí)的地方，這里我們主要介紹Ubuntu ror，包括介紹Ubuntu ror等方面。這篇文章雖然是將Ubuntu ror的,但是對于整個web開發(fā)還是非常有意義的，我也總結(jié)了下這篇文章，發(fā)現(xiàn)web程序還是很有共性的.
1:負(fù)載均衡器
大型網(wǎng)站肯定不是單臺服務(wù)器的,為了做負(fù)載均衡,一般用F5,DNS輪詢.我們公司所有的靜態(tài)頁面則采用NGINX做代理,后端掛SQUID服務(wù)器.NGINX的代理模塊能夠根據(jù)url地址HASH到某組服務(wù)器上,NGINX做負(fù)載均衡,SQUID組則考慮容災(zāi)問題.
2:WEB緩存服務(wù)器
原來我們公司使用文件cache,在新版本中使用squid作為頁面緩存,squid組根據(jù)不同地區(qū)做IDC分布,形成了分布式的系統(tǒng).從實際效果上看,文件cache更容易控制,程序使用比較靈活.考慮到不同的應(yīng)用ncache可能逐步替代squid.
3:后端服務(wù)器
后端服務(wù)器就是應(yīng)用服務(wù)器,主要通過F5掛在squid服務(wù)集群后面,處理的都是動態(tài)請求,每臺機器每天50萬的請求,cpu負(fù)載也不高,并發(fā)請求沒有超過100,使用的是apache1.3,lamp的組合.
JavaEye網(wǎng)站的Ubuntu ror性能優(yōu)化經(jīng)驗談
在這一年半的時間里，JavaEye網(wǎng)站的每日PV從最開始的5萬，緩慢增長到了現(xiàn)在的60萬。隨著網(wǎng)站負(fù)載的不斷增加，我們也在不斷嘗試和調(diào)整網(wǎng)站的性能，積累了不少第一手Ubuntu ror應(yīng)用性能優(yōu)化的實戰(zhàn)經(jīng)驗。雖然我們并不是Ubuntu ror性能優(yōu)化的權(quán)威專家，我們所積累的經(jīng)驗也許并不是最優(yōu)實踐，但是作為國內(nèi)最早涉足Ubuntu ror商業(yè)運營的互聯(lián)網(wǎng)網(wǎng)站之一，我們非常樂意分享和交流我們的實戰(zhàn)經(jīng)驗，以幫助后來者節(jié)省必要的摸索時間。
Ubuntu ror驚人的開發(fā)速度恐怕是每個互聯(lián)網(wǎng)創(chuàng)業(yè)者都夢寐以求的，但是隨著網(wǎng)站流量的不斷增大，可能大多數(shù)采用Ubuntu ror的網(wǎng)站或遲或早會遇到Ubuntu ror的性能瓶頸，我的一個朋友capitian說過一句很有意思的話：“Ubuntu ror應(yīng)用做到后來，總有自己修改底層的沖動”。就我所了解和掌握的情況來看，很多Ubuntu ror網(wǎng)站都過早的遇到了性能瓶頸，一個很普遍的現(xiàn)象就是：Ubuntu ror應(yīng)用的CPU負(fù)載要遠(yuǎn)遠(yuǎn)高于數(shù)據(jù)庫的負(fù)載。這是一個有點違背常理的現(xiàn)象，因為我們知道，硬盤IO速度要比內(nèi)存慢得多，所以一般Web應(yīng)用的性能瓶頸往往會出現(xiàn)在數(shù)據(jù)庫IO上，因此優(yōu)化數(shù)據(jù)庫訪問，進(jìn)行對象緩存是非常有效的性能優(yōu)化手段。但是一旦應(yīng)用服務(wù)器負(fù)載比數(shù)據(jù)庫還高的話，單純的對象緩存就無用武之地了。下面我們從幾個方面分別談一談如何進(jìn)行Ubuntu ror的性能優(yōu)化：
應(yīng)用的部署
Ubuntu ror應(yīng)用的部署包括操作系統(tǒng)，Web服務(wù)器，應(yīng)用服務(wù)器和數(shù)據(jù)庫四個方面：
一、操作系統(tǒng)
1、發(fā)行版本
Ubuntu ror適合于部署在Unix類操作系統(tǒng)上面，通常比較多的人使用RHEL/CentOS/Ubuntu，我們比較偏愛SuSE Linux，對于我們服務(wù)器使用的AMD Opteron x86_64的CPU來說，SLES要比RHEL有更多的優(yōu)化。另外應(yīng)該盡量使用64位版本操作系統(tǒng)，以充分發(fā)揮x86_64 CPU的性能，并且x86_64的Linux很多Kernel參數(shù)也大很多，代價就是需要更多的物理內(nèi)存。
2、文件系統(tǒng)
Linux最常用的文件系統(tǒng)是ext3，但我們使用的是Reiserfs文件系統(tǒng)。Reiserfs在讀寫大量小文件的目錄性能非常高，即使處理目錄下面直接存放10萬個文件，性能仍然不會下降。我們知道默認(rèn)情況Rails會對每個瀏覽器會話在硬盤生成session文件，一個繁忙的網(wǎng)站，臨時文件目錄下面有上萬乃至幾萬個session文件是很常見的現(xiàn)象。對于這種目錄下面幾萬個小文件的存取，reiserfs要比ext3性能高一個數(shù)量級。如果希望對session文件有更好的存取性能，可以把臨時目錄鏈接到Linux的內(nèi)存文件系統(tǒng)/dev/shm目錄下面，這樣實際上session文件的存取都是直接內(nèi)存操作了，這種方式唯一的問題在于不能支持群集部署。如果你已經(jīng)升級到了Rails2.0，可以采取把session保存到Cookie里面的方式，既可以避免服務(wù)器處理session的開銷，而且還支持群集部署，是大規(guī)模網(wǎng)站部署的首選方式。
3、內(nèi)核的網(wǎng)絡(luò)參數(shù)調(diào)整
對于流量很大的網(wǎng)站來說，默認(rèn)的Linux內(nèi)核網(wǎng)絡(luò)參數(shù)偏小，因此如果你的網(wǎng)站流量非常大，或者上傳下載大文件比較多，可以針對性的調(diào)整內(nèi)核網(wǎng)絡(luò)參數(shù)，擴大內(nèi)核的TCP接收數(shù)據(jù)和發(fā)送數(shù)據(jù)的Buffer緩沖區(qū)大小，比方說：
引用
net.core.rmem_default=262144
net.core.wmem_default=262144
net.core.rmem_max=262144
net.core.wmem_max=262144
net.ipv4.tcp_rmem=4096 65536 524288
net.ipv4.tcp_wmem=4096 65536 524288
參數(shù)具體調(diào)整，可以Google相關(guān)的Linux內(nèi)核參數(shù)的文檔，這里不展開詳談。
二、Web服務(wù)器
Web服務(wù)器首選Lighttpd，因為Lighttpd在和后端的應(yīng)用服務(wù)器通訊方式上做了足夠的優(yōu)化：當(dāng)POST大數(shù)據(jù)量的時候，Lighttpd在完整的接收客戶端瀏覽器的數(shù)據(jù)之后，才會一次性發(fā)送給應(yīng)用服務(wù)器；同樣的，Lighttpd也是一次性把應(yīng)用服務(wù)器處理的頁面數(shù)據(jù)全部接收，不設(shè)置Buffer Size的限制。因此Lighttpd能夠盡最大可能的減輕應(yīng)用服務(wù)器的負(fù)擔(dān)，減少應(yīng)用服務(wù)器用于處理數(shù)據(jù)傳輸?shù)难舆t，更加有效的利用應(yīng)用服務(wù)器資源。這方面的詳細(xì)的論述請看：Ubuntu ror部署方案深度剖析。
關(guān)于Lighttpd的安裝可以參考在Linux平臺上安裝和配置Ruby on Rails詳解，這里僅談Lighttpd的性能優(yōu)化的幾個要點：
1、網(wǎng)絡(luò)IO調(diào)度方式
Linux Kernel 2.6支持sysepoll方式調(diào)度網(wǎng)絡(luò)IO，能夠處理極高的并發(fā)連接請求，Lighttpd可以通過配置文件打開sysepoll支持：
引用
server.event-handler = "linux-sysepoll"
2、網(wǎng)絡(luò)IO傳輸方式
Linux Kernel 2.6支持sendfile方式傳輸數(shù)據(jù)，Lighttpd可以通過配置文件打開sendfile支持：
引用
server.network-backend = "linux-sendfile"
此外Lighttpd還支持應(yīng)用服務(wù)器參與的文件下載控制X-sendfile，詳細(xì)的論述請看：Ubuntu ror網(wǎng)站如何利用lighttpd的X-sendfile功能提升文件下載性能
3、文件狀態(tài)緩存
Lighttpd通過stat()調(diào)用獲得文件被修改的信息，來決定當(dāng)請求同一個靜態(tài)文件資源的時候，是否需要再次讀取硬盤文件。但是每次stat()調(diào)用也有一定的開銷，Lighttpd支持通過Fam Server來減少stat調(diào)用。即每次當(dāng)文件被修改之后，Kernel會發(fā)送一個消息通知Fam Server，而Lighttpd會通過進(jìn)程間通訊連接Fam Server，可以知道文件是否被修改的信息，不必再每次調(diào)用stat()。
引用
server.stat-cache-engine = "fam"
4、限定POST Size
為了避免黑客惡意的攻擊服務(wù)器，偽造超大Post數(shù)據(jù)包轟炸Web服務(wù)器和應(yīng)用服務(wù)器，可以限制Request請求的大小，例如限制為10MB：
引用
server.max-request-size = 10240
5、日志文件
Lighttpd是單進(jìn)程單線程的服務(wù)器，調(diào)度網(wǎng)絡(luò)IO性能是極高的，但是在某些極端情況下，單進(jìn)程服務(wù)器也有風(fēng)險，即一旦被某操作系統(tǒng)調(diào)用掛住，整個服務(wù)器就沒有辦法響應(yīng)請求了。比方說服務(wù)器其他進(jìn)程導(dǎo)致的IO WAIT很高，操作系統(tǒng)的buffer又不夠的時候，Lighttpd在大量的寫access log就有被掛住的可能性。因此如果Lighttpd日志對你的參考價值不大，可以考慮關(guān)閉掉。像JavaEye網(wǎng)站每天Lighttpd產(chǎn)生430萬條log，對硬盤IO也是一個不小的負(fù)擔(dān)，既然已經(jīng)開著Rais的production.log，那么Lighttpd的access log沒什么參考價值了，那就關(guān)掉它。
Lighttpd的性能優(yōu)化請看其作者寫的文章：
http://trac.lighttpd.net/trac/wiki/Docs%3APerformance
三、應(yīng)用服務(wù)器
Ruby的應(yīng)用服務(wù)器可以使用FastCGI，或者M(jìn)ongrel，如果我們使用Lighttpd的話，F(xiàn)astCGI是最好的搭配。
1、FastCGI和Lighttpd的通訊方式
如果FastCGI和Lighttpd是在同一臺服務(wù)器，那么建議采用Unix Socket通訊，這種通訊方式比TCP要快一些，F(xiàn)astCGI可以通過Lighttpd自帶的spawn-fcgi命令行工具啟動，創(chuàng)建socket文件，而Lighttpd監(jiān)聽socket文件。如果兩者不在同一臺服務(wù)器，需要群集部署，那就必須采用TCP Socket通訊，方式是一樣的。
2、FastCGI進(jìn)程應(yīng)該開多少個合適？
Rails是單進(jìn)程方式運行的，理論上來說，開幾個FastCGI進(jìn)程，就只能并發(fā)響應(yīng)幾個請求。對于繁忙的網(wǎng)站來說，峰值期間每秒有幾十個動態(tài)請求是很正常的事情，但實際上FastCGI進(jìn)程并不需要開那么多。這是因為前端的Web服務(wù)器在處理用戶瀏覽器連接，發(fā)送Request請求需要相當(dāng)長的時間，在FastCGI處理完請求釋放該連接以后，Web服務(wù)器還需要相當(dāng)長的時間才能把頁面數(shù)據(jù)完整的發(fā)送到客戶端瀏覽器。用戶在點擊一個鏈接以后，等待1-2秒，頁面內(nèi)容就顯示出來，這對用戶的感覺來說已經(jīng)是非常快的了，而FastCGI用于處理該請求可能只需要0.1秒，那么一個FastCGI進(jìn)程雖然并不能夠真正的并發(fā)運行，但實際上的效果是他可以在1秒之內(nèi)處理10個請求，讓10個用戶在同時訪問網(wǎng)站的過程當(dāng)中感覺不到明顯的延遲。
因此FastCGI需要開多少個，取決于你的網(wǎng)站峰值期間每秒有多少個用戶請求過來，而你的FastCGI又能夠以多快的速度處理請求。比方說你的網(wǎng)站峰值期間每秒有50個動態(tài)請求，F(xiàn)astCGI在峰值期間處理每個請求需要0.2秒，那么實際上你只需要開10個FastCGI進(jìn)程就足夠了，為了應(yīng)付突發(fā)的峰值請求，你可以在這個計算量上面增加一些余量，比方說15-20個進(jìn)程，肯定是綽綽有余了。
關(guān)于FastCGI的性能優(yōu)化，可以參考Lighttpd作者的文章，雖然他是針對PHP跑FastCGI寫的，但對Ubuntu ror也有參考價值：
http://trac.lighttpd.net/trac/wiki/Docs%3APerformanceFastCGI
四、數(shù)據(jù)庫
JavaEye網(wǎng)站使用MySQL5.0.XX版本，數(shù)據(jù)庫引擎是InnoDB。關(guān)于MySQL數(shù)據(jù)庫的調(diào)優(yōu)，推薦大家看MySQL Performance Blog，作者是一個MySQL性能調(diào)優(yōu)方面的專家，并且提供MySQL咨詢服務(wù)。他的博客上面有很豐富的關(guān)于MySQL調(diào)優(yōu)的文章和演講文稿，特別是關(guān)于InnoDB方面，非常深入。JavaEye的數(shù)據(jù)庫調(diào)優(yōu)就是根據(jù)他的InnoDB演講文稿來調(diào)整的，一般說來，有幾個需要調(diào)整的參數(shù)：
innodb_buffer_pool_size
這個參數(shù)很重要，越大越好，對于專用的數(shù)據(jù)庫服務(wù)器一般建議開服務(wù)器內(nèi)存的50%以上。
query_cache_size
查詢緩存，對于查詢的性能提高有很大幫助，但不宜開得過大，查詢緩存的過期可能很頻繁，過大查詢緩存反而降低性能，增加服務(wù)器開銷
innodb_flush_method = O_DIRECT
針對InnoDB的數(shù)據(jù)文件，關(guān)閉操作系統(tǒng)的文件緩沖，由于InnoDB自己有巨大的Buffer Pool，操作系統(tǒng)對文件的讀寫緩沖功能反而會降低MySQL的InnoDB的IO性能。
最后針對數(shù)據(jù)庫的SQL優(yōu)化來說有兩點原則：
1、對數(shù)據(jù)庫表要適當(dāng)?shù)膭?chuàng)建索引
特別是出現(xiàn)在where查詢條件當(dāng)中字段，和關(guān)聯(lián)查詢當(dāng)中的外鍵，要高度注意。
2、盡量避免大表的全表掃描和數(shù)據(jù)庫的硬盤IO
查詢比較慢的SQL要explain一下，看看是否發(fā)生了全表掃描，采取各種措施減少或者避免大表的全表掃描問題，例如拆分表等等。
最后針對MySQL數(shù)據(jù)庫運行情況，我們可以用show status; 和 show innodb status\G 來監(jiān)測。
【編輯推薦】
