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