CentOS WEB緩存服務器程序使用比較靈活
CentOS WEB對于電腦使用的玩家的常用軟件，然后我就學習及深入的研究CentOS WEB，在這里和大家一起探討CentOS WEB的使用方法，希望對大家有用。
CentOS WEB 架構布置
1:負載均衡器大型網站肯定不是單臺服務器的,為了做負載均衡,一般用F5,DNS輪詢.我們公司所有的靜態頁面則采用NGINX做代理,后端掛SQUID服務器.NGINX的代理模塊能夠根據url地址HASH到某組服務器上,NGINX做負載均衡,SQUID組則考慮容災問題.
2:CentOS WEB緩存服務器原來我們公司使用文件cache,在新版本中使用squid作為頁面緩存,squid組根據不同地區做IDC分布,形成了分布式的系統.從實際效果上看,文件cache更容易控制,程序使用比較靈活.考慮到不同的應用ncache可能逐步替代squid.
3:后端服務器后端服務器就是應用服務器,主要通過F5掛在squid服務集群后面,處理的都是動態請求,每臺機器每天50萬的請求,cpu負載也不高,并發請求沒有超過100,使用的是apache1.3,lamp的組合.
JavaEye網站的RoR性能優化經驗談
JavaEye網站從2006年9月11日上線基于RoR的2.0版本開始，到現在已經運行了將近一年半了。在這一年半的時間里，JavaEye網站的每日PV從最開始的5萬，緩慢增長到了現在的60萬。隨著網站負載的不斷增加，我們也在不斷嘗試和調整網站的性能，積累了不少第一手RoR應用性能優化的實戰經驗。
雖然我們并不是RoR性能優化的權威專家，我們所積累的經驗也許并不是最優實踐，但是作為國內最早涉足RoR商業運營的互聯網網站之一，我們非常樂意分享和交流我們的實戰經驗，以幫助后來者節省必要的摸索時間。
RoR驚人的開發速度恐怕是每個互聯網創業者都夢寐以求的，但是隨著網站流量的不斷增大，可能大多數采用RoR的網站或遲或早會遇到RoR的性能瓶頸，我的一個朋友capitian說過一句很有意思的話：“RoR應用做到后來，總有自己修改底層的沖動”。
就我所了解和掌握的情況來看，很多RoR網站都過早的遇到了性能瓶頸，一個很普遍的現象就是：RoR應用的CPU負載要遠遠高于數據庫的負載。這是一個有點違背常理的現象，因為我們知道，硬盤IO速度要比內存慢得多，所以一般CentOS WEB應用的性能瓶頸往往會出現在數據庫IO上，因此優化數據庫訪問，進行對象緩存是非常有效的性能優化手段。但是一旦應用服務器負載比數據庫還高的話，單純的對象緩存就無用武之地了。下面我們從幾個方面分別談一談如何進行RoR的性能優化：
應用的部署RoR應用的部署包括操作系統，CentOS WEB服務器，應用服務器和數據庫四個方面：
一、操作系統
1、發行版本
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內核參數的文檔，這里不展開詳談。
二、CentOS WEB服務器
CentOS WEB服務器首選Lighttpd，因為Lighttpd在和后端的應用服務器通訊方式上做了足夠的優化：當POST大數據量的時候， Lighttpd在完整的接收客戶端瀏覽器的數據之后，才會一次性發送給應用服務器；同樣的，Lighttpd也是一次性把應用服務器處理的頁面數據全部接收，不設置Buffer Size的限制。因此Lighttpd能夠盡最大可能的減輕應用服務器的負擔，減少應用服務器用于處理數據傳輸的延遲，更加有效的利用應用服務器資源。這方面的詳細的論述請看：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，詳細的論述請看：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數據包轟炸CentOS 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:Performance
三、應用服務器
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進程并不需要開那么多。這是因為前端的CentOS WEB服務器在處理用戶瀏覽器連接，發送Request請求需要相當長的時間，在FastCGI處理完請求釋放該連接以后，CentOS WEB服務器還需要相當長的時間才能把頁面數據完整的發送到客戶端瀏覽器。
用戶在點擊一個鏈接以后，等待1-2秒，頁面內容就顯示出來，這對用戶的感覺來說已經是非常快的了，而FastCGI用于處理該請求可能只需要0.1秒，那么一個FastCGI進程雖然并不能夠真正的并發運行，但實際上的效果是他可以在1秒之內處理10個請求，讓10個用戶在同時訪問網站的過程當中感覺不到明顯的延遲。
因此FastCGI需要開多少個，取決于你的網站峰值期間每秒有多少個用戶請求過來，而你的FastCGI又能夠以多快的速度處理請求。比方說你的網站峰值期間每秒有50個動態請求，FastCGI在峰值期間處理每個請求需要0.2秒，那么實際上你只需要開10個FastCGI進程就足夠了，為了應付突發的峰值請求，你可以在這個計算量上面增加一些余量，比方說15-20個進程，肯定是綽綽有余了。
關于FastCGI的性能優化，可以參考Lighttpd作者的文章，雖然他是針對PHP跑FastCGI寫的，但對RoR也有參考價值：
http://trac.lighttpd.net/trac/wiki/Docs:PerformanceFastCGI
四、數據庫
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 來監測。
Rails應用程序的優化Rails應用程序優化包括ruby解析器的優化，緩存的使用，以及應用代碼級別的優化。Stefans Kaes曾經在Railsconf 2006有一個Rails應用程序優化的演講，他的演講PPT是極好的Rails性能優化指南，可以在這里下載:http://www.javaeye.com/topic/24508。
他還編寫了一個用于Rails性能測試的軟件包RailsBench，大家可以參考。由于Stefans Kaes的代碼優化文檔已經寫的非常詳細了，因此我就不在一一復述，只提出幾點對性能影響比較大的方面：
一、ruby解析器的優化
ruby的解析器性能是很糟糕的，ruby早期的主要用途是取代perl寫批量處理的腳本的，并不是為服務器應用編寫的，因此在內存分配策略上非常不適合服務器應用。Stefans Kaes編寫了一個ruby GC的補丁文件，在railsbench下載包里面提供了。雖然當前Railsbench提供的GC補丁只有針對ruby 1.8.4和1.8.5版本的，但是在ruby 18,6上面使用1.8.5的GC補丁也完全沒有問題。
GC補丁的作用主要是針對Rails應用開大了ruby的內存堆，可以有效提高內存堆的利用率，降低GC的頻率。根據Stefans Kaes提供的測試數據，打補丁并且調整參數以后，GC的頻率下降到只有原來的1/10還不到。降低GC頻率盡管并不能夠提高單個請求的執行速度，但是可以增加整體應用的負載能力。
我們在JavaEye的服務器上也使用了GC補丁，并且根據推薦參數進行了調整。在使用GC補丁之后，CentOS WEB服務器的CPU負載下降了大概15%左右，效果非常顯著。當然開大內存堆的代價就是ruby進程會多消耗內存，在我們的服務器上，ruby打補丁之后多消耗了50%左右的物理內存。
二、緩存的使用
1、對象緩存
JavaEye上面關于對象緩存的討論很多，我們也提供了JavaEye這方面很多數據，因此不展開了。RoR可以使用兩個對象緩存，一個是 CachedModel，類似Hibernate，比較簡單，對Model的CRUD操作自動進行緩存；另外一個是cache_fu，需要自己編碼來添加對象緩存，但提供了更多高級機制，目前我們使用的是cache_fu。在使用對象緩存的情況下，應該把查詢方法的:include去掉，避免關聯查詢無法利用緩存的現象。
2、查詢緩存
對于統計類耗時查詢，如果不要求實時性，那么可以使用memcache-client將查詢結果緩存到memcached里面，例如博客排行榜之類。
3、頁面局部緩存
對象緩存和查詢緩存都是降低數據庫訪問負載的，但如果RoR的負載很高，那么只能依靠頁面局部緩存了。傳統的互聯網CentOS WEB1.0網站很流行采用動態頁面靜態化技術來提高網站的負載，但是對于CentOS WEB2.0網站來說，每個頁面都帶有登陸用戶的個人信息，頁面的很多部分需要實時更新，例如投票，點擊統計， digg，顯示用戶在線狀態等等，動態頁面靜態化非常困難。當然如果你非要采用動態頁面靜態化，技術上也不是實現不了，可以通過AJAX請求來處理靜態頁面的動態部分，但是這種解決方案的開發成本過高，而且性能未必會有明顯的改善，大家看看新浪和搜狐博客就知道這種技術被應用的有多糟糕了。
CentOS WEB2.0網站比較常用使用頁面局部緩存，一種情況是頁面不需要實時更新的，那么只需要設置一個合理的過期時間就行了，這種情況我們目前使用的比較多；另外一種情況是雖然不需要實時更新，但是會在用戶執行某些操作后需要緩存過期，比方說博客個人主頁的很多頁面，這種情況下緩存過期策略會比較復雜，考慮到合理的開發成本，我們尚未對這樣的頁面使用局部緩存。
此外，Rails的頁面局部緩存有一個缺點，就是和頁面查詢結果對應的Action當中的查詢語句要放在View里面，否則每次action里面的查詢還是會被執行，但是這樣做會破壞程序代碼良好的MVC結構。這種情況下，也可以采用另外一個Cache插件: better rails caching，在緩存頁面的同時可以緩存Action當中的查詢語句。
三、應用代碼的優化
Stefans Kaes的文檔里面對應用代碼的優化進行了非常詳細的介紹，因此我這里只提兩個比較重要的注意事項：
1、link_to
Rails的link_to是非常慢的，它的代碼實現過于復雜，特別是Rails1.2引入了REST以后，大量的命名路由被使用，這些命名路由還需要通過一次method_missing，那就更加緩慢了。因此對于被頻繁使用的內部URL地址，一定要自己用字符串拼接方式改寫，可以很明顯提高View的 render性能。此外類似的helper還有很多，例如button_tag，image_tag啥啥的，如非必要，盡量不用他的helper
2、正則表達式
ruby的正則表達式也是極慢，例如auto_fix這個helper的正則表達式就比較復雜，CentOS WEB造成的結果就是一但大量使用auto_fix，View的 render就明顯變慢，類似依賴正則表達式進行字符串過濾的helper有很多，如果需要頻繁大量使用，請先自行做benchmark。
Rails應用程序的內存泄漏問題和解決
內存泄漏是服務器端程序經常遇到的，CentOS WEB有時候內存泄漏問題會讓人很頭疼，總體來說，Rails的內存泄漏問題比Java要少得多，這是因為Java內存泄漏最常見的三種情況在Rails當中不存在：
1、HttpSession導致的內存泄漏
Java程序員喜歡往session里面丟很多東西，最糟糕的是竟然有很多框架軟件也肆無忌憚往session里面丟狀態數據，但Rails的session是不放在內存里面的，所以無此煩惱。
2、數據庫連接釋放不徹底
Java的數據庫連接池釋放不徹底，以及查詢游標釋放不徹底，都必然導致內存泄漏。Rails沒有數據庫連接池，而是每個進程持有一個長連接，因此不存在這個問題，而且由于持有長連接，也不存在Java里面的OpenSessionInView的煩惱。
3、用靜態變量持有全局共享數據
Java程序員很喜歡通過靜態全局變量來持有共享數據，CentOS WEB但共享數據忘記清理的話，也很容易導致內存泄漏，Ruby是SNA架構，多進程服務器模式，進程間無法共享數據，反而避免了全局共享數據帶來的麻煩。
但是Rails應用有一種情況：在Ruby代碼中調用C寫的第三方ruby類庫的時候，CentOS WEB很容易導致內存泄漏，但這種內存泄漏反而在Java中極其罕見。Ruby本身有GC來管理內存堆，但是代碼一旦調用C寫的第三方ruby類庫，內存堆的分配權就掌握在第三方C庫的實現上面了，如果這個C庫的代碼質量不夠好，內存泄漏就不可避免。由于ruby本身性能很差，因此計算量大的功能往往依賴底層的C庫來實現，這下內存泄漏的潘多拉魔盒就打開了！而Java 性能比較好，功能都是純Java編寫，基本上看不到需要依賴第三方C庫的情況，因此比較安全。
JavaEye也面臨著內存泄漏的困擾，CentOS WEB這方面困擾主要來自于Rmagic。Rmagick調用ImageMagick的C庫來完成圖片的操作，從我們的監測來看，RMagick大多數情況下會緩慢的泄漏內存，在某些特定的圖片操作上會急劇的泄漏內存。解決辦法就是用mini_magick替代 Rmagick，mini_magick是直接調用ImageMagick的mogrify命令，另起一個進程來操作圖片，操作完進程就結束了，絕無后患，由于Linux的fork進程開銷不大，因此也不必擔心性能問題。
此外，調用第三方C庫的ruby代碼編寫都需要高度小心，比方說JavaEye使用ferret實現全文檢索，根據應用的需要調用ferret的 API來編寫自己的analyzer，其中在實現token_stream方法上面使用了XXXAnalyzer.new和XXXToken.new， XXXFilter.new，結果內存急劇泄漏，經過檢查發現是Analyzer對象不能被反復創建，改成創建后緩存該對象就好了，但是Filter和 Token對象卻必須每次創建，此外ferret的PerAnalyzerFilter也有內存泄漏問題。由于類庫是用C編寫的，單純看API文檔或者看源代碼片斷一般無法判斷出里面的內存泄漏陷阱的。
當遇到了難以解決和定位的內存泄漏問題，Ruby也有類似Java的內存Profiler工具：
1、Memory Profiler
一個純ruby編寫的內存探測器，原理很簡單，就是用ruby的對象引用計數器ObjectSpace.each_object去遍歷內存堆中的每個 ruby對象，進行統計和分析。用起來很簡單，非常適合于開發環境下偵測內存泄漏問題，但不能用在生產環境下，極度影響Rails性能。
2、Bleak_house
Bleak_house給Ruby解析器打了補丁，插入相關的指令，可以從底層探測整個ruby內存堆中對象的情況，然后你可以定期dump出來完整的內存堆里面的所有對象，再用bleak工具去分析dump文件，他比上面的工具分析的信息要全面，可以在測試環境和預發布環境下使用，但在生產環境下，也會對應用的性能產生很大的影響，要慎用。
JavaEye網站在RoR性能方面的經驗就全部分享給大家了，也希望做RoR的朋友都拿出來自己的經驗和大家分享，共同學習和促進RoR的應用和普及。
【編輯推薦】
