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