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