http://www.centoscn.com/CentosSecurity/SoftSecurity/2014/0422/2840.html
一、 基於動態內容爲主的網站優化案例
1．網站運行環境說明
硬件環境：1臺IBM x3850服務器, 單個雙核Xeon 3.0G CPU，2GB內存，3塊72GB SCSI磁盤。
操作系統：CentOS5.4。
網站架構：Web應用是基於LAMP架構，所有服務都在一臺服務器上部署。
2．性能問題現象及處理措施
現象描述：
網站在上午10點左右和下午3點左右訪問高峯時，網頁無法打開，重啓服務後，網站能在一段時間內能正常服務，但過一會又變得響應緩慢，最後網頁徹底無法打開。
檢查配置：
首先檢查系統資源狀態，發現服務出現故障時系統負載極高，內存基本耗盡，接着檢查Apache配置文件httpd.conf，發現“MaxClients”選項值被設置爲2000，並且打開了Apache的KeepAlive特性。
處理措施：
根據上面的檢查，初步判斷是Apache的”MaxClients“選項配置不當引起的，因爲系統內存僅有2GB大小，而“MaxClients”選項被 配置爲2000，過多的用戶訪問進程耗盡了系統內存；然後，修改httpd.conf配置文件的“MaxClients”選項，將此值由2000降到 1500；繼續觀察發現，網站還是頻繁宕機，於是又將“MaxClients”選項值降到1024，觀察一段時間發現，網站服務宕機時間間隔加長了，不像 以前那麼頻繁，但是系統負載還是很高，網頁訪問速度極慢。
3．第一次分析優化
既然是由系統資源耗盡導致的網站服務失去響應，那麼就深入分析系統資源的使用情況，通過uptime、vmstat、top、ps等命令的聯合使用，得出如下結論：
系統平均負載很高，通過uptime輸出的系統“load average”值都在10以上，而CPU資源也消耗嚴重，這是造成網站響應緩慢或長時間沒有響應的主要原因，而導致系統資源消耗過高的主要依據是用戶進程消耗資源嚴重。
原因分析
通過top命令發現，每個Apache子進程消耗將近6~8MB左右內存，這是不正常的。根據經驗，在正常情況下每個Apache子進程消耗的內存在 1MB左右，結合Apache輸出日誌發現，網站首頁訪問頻率最高，也就是說首頁程序代碼可能存在問題。於是檢查首頁的PHP代碼，發現首頁的頁面非常 大，圖片很多，並且由全動態的程序組成，這樣每次用戶訪問首頁都要多次查詢數據庫，而查詢數據庫是個非常耗費CPU資源的過程，並且首頁PHP代碼也沒有 相應的緩存機制，每個用戶請求都要重新進行數據庫查詢操作，數據庫查詢負荷有多高可想而知。
處理措施
修改首頁PHP代碼，縮減頁面大小，並且對訪問頻繁的操作增加緩存機制，儘量減少程序對數據庫的訪問。
4．第二次分析優化
通過前面簡單優化，系統服務宕機現象出現次數減少很多，但是在訪問高峯時網站偶爾還會無法正常訪問。這次仍然從分析系統資源使用狀況入手，發現系統內存資源消耗過大，並且磁盤I/O有等待問題,於是得出如下結論：
原因分析
內存消耗過大，肯定是用戶訪問進程數過多導致的，在沒有優化PHP代碼之前，每個Apache子進程消耗6~8MB內存，如果設置Apache的最大用戶 數爲1024，那麼內存耗盡是必然的，當物理內存耗盡時，虛擬內存就會啓用，頻繁地使用虛擬內存，肯定會出現磁盤I/O等待問題，最終導致CPU資源耗 盡。
處理措施
通過上面對PHP代碼的優化，每個Apache子進程消耗的內存資源基本維持在1~2MB左右，因此修改Apache配置文件httpd.conf中 的”MaxClients”選項值爲“600”，同時把Apache配置中的“KeepAlive”特性關閉，這樣Apache進程數大量減少，基本維持 在500~600之間，雖然偶爾也會使用虛擬內存，但是Web服務正常了，服務宕機問題也很少出現了。
5．第三次分析優化
經過前兩次的優化，網站基本運行正常，但是在訪問高峯時偶爾還會出現站點無法訪問得現象，繼續進行問題分析，通過命令查看系統資源，發現仍是CPU資源耗盡導致的，但是與前兩次又有所不同：
原因分析
通過觀察後臺日誌，發現PHP程序有頻繁訪問數據庫的操作，大量的SQL語句中有where, order by等子句；同時，數據庫查詢過多，大部分都是複雜查詢，一般都需要遍歷全表，而大量的表沒有建立索引，這樣的程序代碼導致MySQL數據庫負荷過高，而 MySQL數據庫和Apache部署在同一臺服務器上，這也是導致服務器消耗CPU資源過高的原因。
處理措施
優化程序中的SQL語句，增加where子句上的匹配條件，減少遍歷全部的查詢，同時在where和order by子句的字段上建立索引，並且增加程序緩存機制，通過這次優化，網站運行基本處於正常狀態，再也沒有出現宕機的現象。
6．第四次優化分析
通過前面三次優化以後，網站在程序代碼、操作系統、Apache等方面的優化空間越來越小，要避免出現服務氣宕機現象，並且保證網站穩定、高效、快速地運 行，可以從網站結構上進行優化，也就是將Web和數據庫分離部署，可以增加一臺專用的數據庫服務器，單獨部署MySQL數據庫。隨着訪問量的增加，如果前 端無法滿足訪問請求，還可以增加多臺Web服務器，Web服務器之間進行負載均衡部署，解決前端性能瓶頸；如果在數據庫端還存在讀寫壓力，還可以繼續增加 一臺MySQL服務器，將MySQL進行讀寫分離部署，這樣一套高性能、高可靠的網站系統就構建起來了。
二、 基於動態、靜態內容結合的網站優化案例
1．網站運行環境說明
硬件環境：兩臺IBM x3850服務器, 單個雙核Xeon 3.0G CPU，4GB內存，3塊72GB SCSI磁盤。
操作系統：CentOS5.4。
網站架構：Web應用是基於J2EE架構的電子商務應用，Web端應用服務器是Tomcat，採用MySQL數據庫，Web和數據庫獨立部署在兩臺服務器上。
2．性能問題現象以及處理措施
現象描述
網站訪問高峯時，網頁無法打開，重啓Java服務後，網站可以正常運行一段時間，但過一會又變得響應緩慢，最後網頁徹底無法打開。
檢查配置
首先檢查系統資源狀態，發現服務出現故障時系統負載極高，CPU滿負荷運行，Java進程佔用了系統99%的CPU資源，但內存資源佔用不大；接着檢查應 用服務器信息，發現只有一個Tomcat在運行Java程序；接着查看Tomcat配置文件server.xml，發現server.xml文件中的參數 都是默認配置，沒有進行任何優化。
處理措施
server.xml文件的默認參數需要根據應用的特性進行適當的修改，例如可以修改“connectionTimeout“、 “maxKeepAliveRequests”、“maxProcessors”等幾個Tmcat配置文件的參數，適當加大這幾個參數值。修改參數值後， 繼續觀察發現，網站服務宕機時間間隔加長了，不像以前那麼頻繁，但是Java進程消耗CPU資源還是很嚴重，網頁訪問速度極慢。
3．第一次分析優化
既然Java進程消耗CPU資源嚴重，那麼需要查看到底是什麼導致Java消耗資源嚴重，通過lsof、netstat命令發現有大量的Java請求等待 信息，然後查看Tomcat日誌，發現大量報錯信息、日誌提示和數據庫連接超時，最終無法連接到數據庫，同時，訪問網站靜態資源，也無法訪問，於是得出如 下結論：
原因分析
Tomcat本身就是一個Java容器，是使用連接/線程模型處理業務請求的，主要用於處理Jsp、servlet等動態應用，雖然它也能當作HTTP服 務器，但是處理靜態資源的效率很低，遠遠比不上Apache或Nginx。從前面觀察到的現象分析，可以初步判斷是Tomcat無法及時響應客戶端的請 求，進而導致請求隊列越來越多，直到Tomcat徹底崩潰。對於一個正常的訪問請求來說，服務器接收到請求後，會把請求交給Tomcat去處 理，Tomcat接着執行編譯、訪問數據庫等操作，然後把信息返回給客戶端，客戶端接收到信息後，Tomcat就關閉這個請求鏈接，這樣一個完整的訪問過 程就結束了。而在高併發訪問狀態下，很多的請求瞬間都交給Tomcat處理，這樣Tomcat還沒有完成第一個請求，第二個請求就來了，接着是第三個，等 等，這樣越積越多，Tomcat最終失去響應， Java進程就會處於僵死狀態，資源無法釋放，這就是根本原因。
處理措施
要優化Tomcat性能，需要從結構上進行重構，首先，加入Apache支持，由Apache處理靜態資源，由Tomcat處理動態請求，Apache服 務器和Tomcat服務器之間使用Mod_JK模塊進行通信。使用Mod_JK模塊的好處是：它可以定義詳細的資源處理規則，根據動態、靜態網站的特點， 將靜態資源文件全部交給Apache處理，而動態請求通過Mod_JK模塊傳給Tomcat去處理，通過Apache+JK+Tomcat的整合，可以大 幅度提高Tomcat應用的性能。
4．第二次分析優化
經過前面的優化措施，Java資源偶爾會增高，但是一段時間後又會自動降低，這屬於正常狀態，而在高併發訪問情況下，Java進程有時還會出現資源上升無法下降的情況，通過查看Tomcat日誌，綜合分析得出如下結論：
要獲得更高、更穩定的性能，單一的Tomcat應用服務器有時會無法滿足需求，因此要結合Mod_JK模塊運行基於Tomcat的負載均衡系統，這樣前端 由Apache負責用戶請求的調度，後端又多個Tomcat負責動態應用的解析操作，通過將負載均分配給多個Tomcat服務器，網站的整體性能會有一個 質的提升。
一、幾種典型應用對系統資源使用的特點
1.1 以靜態內容爲主的Web應用
這 類應用的一個主要特點是小文件居多，並且讀操作頻繁，Web服務器一般爲Apache或Nginx，因爲這兩個HTTP服務器對靜態資源的處理非常迅速和 高效。在Web訪問量不大時，可以直接對外提供服務，但是在有很大併發請求時，單一的Web服務無法支撐大量的客戶端訪問，此時就需要由多臺Web服務器 組成的負載集羣系統。爲了實現更高效的訪問，在最前端還可以搭建Cache服務器，也就是將靜態資源文件緩存到操作系統內存中直接進行讀操作，因爲直接從 內存讀取數據要比從硬盤讀數據效率高很多，所以在Web前端搭建Cache服務器可以大大提高併發訪問性能。常用的Cache軟件有Squid、 Varinsh等。
Cache服務器雖然可以提高訪問性能，但要求服務器有很大的內存，當系統內存充足時，可以緩解磁盤隨機讀的壓力；當內存過小或者內存不足時，系統就會使用虛擬內存，而虛擬內存的使用會引起磁盤I/O的增大，當磁盤I/O增大時，CPU的開銷也隨之增加。
在高併發訪問時，還存在另外一個問題，就是網絡帶寬瓶頸，如果客戶端訪問量很大且帶寬不夠，就會阻塞網絡，影響訪問，因此，在構建基於Web的網絡應用時，網絡帶寬也是必須考慮的一個因素。
1.2 以動態內容爲主的Web應用
這 類應用的一個特點是頻繁地執行寫操作，例如Java、PHP、Perl、CGI等，會導致CPU資源消耗嚴重。因爲動態程序的執行要進行編譯、讀取數據庫 等操作，而這些操作都會消耗CPU資源，因此，一個基於動態程序的Web應用，應該選擇多個性能較高的CPU，這將對系統整體性能的提高有很大幫助。
基 於動態內容的Web應用在高併發訪問時，系統執行的進程數會很多，因此要注意負載的分配。由於過多的進程會消耗大量系統內存，如果內存不足，就會使用虛擬 內存，而虛擬內存的增加會導致磁盤寫操作頻繁，進而消耗CPU資源，因此要尋求一個硬件資源和軟件資源的平衡點，例如配置較大的內存和高性能的CPU，而 在軟件方面可通過如Memcached加快程序與數據庫之間的訪問效率。
1.3 數據庫應用
數 據庫應用的一個主要特點是消耗內存和磁盤I/O，而對CPU的消耗並不是很大，因此最基本的做法就是爲數據庫服務器配置較大的內存和讀寫較快的磁盤陣列， 例如，可以爲數據庫服務器的磁盤選擇RAID5、RAID01等RAID級別。將Web Server與DB Server分離也是優化數據庫應用的一個常用做法。如果客戶端用戶對數據庫的請求過大，還可以考慮採取數據庫的負載均衡方案，通過軟件負載均衡或硬件負 載均衡的方式提高數據庫訪問性能。
對 於數據庫中過大的表，可以考慮進行拆分，也就是將一個大表拆分成多個小表，再通過索引進行關聯處理，這樣可以避免查詢大表造成的性能問題，因爲表太大時， 查詢遍歷全表會造成磁盤讀操作激增，進而出現讀操作等待的情況。同時，數據庫中查詢語句複雜，大量的where子句，order by、group by排序語句等，容易使CPU出現瓶頸。最後，當數據更新時，數據更新量大或更新頻繁，也會造成磁盤寫操作激增，出現寫操作的瓶頸。這些也應該在程序代碼 中避免。
在 日常應用中，還有一種方法可以顯著提高數據庫服務器的性能，那就是讀寫分離。 同時對數據庫進行讀和寫的操作，是效率極低的一種訪問方式，較好的做法是根據讀、寫的壓力和需求，分別建立兩臺結構完全相同的數據庫服務器，將負責寫的臺 服務器上的數據，定時複製給負責讀的服務器，通過讀寫的協作提高系統整體性能。
通 過緩存方式也可以提高數據庫的性能， 緩存是數據庫或對象在內存中的臨時容器，使用緩存可大幅減少數據庫的讀取操作，改由內存來提供數據。比如可以在 Web Server和DB Server之間增加一層數據緩存層，在系統內存中建立被頻繁請求對象的副本，這樣一來，不訪問數據庫也可爲程序提供數據，現在應用很廣泛的 Memcached就是基於這個原理。
1.4 軟件下載應用
靜 態資源下載服務器的主要特點是帶寬消耗嚴重，同時對存儲性能要求也很高，在下載量極高時，可以採用多臺、多點服務器分流形式分擔下載負荷，在HTTP服務 器方面，從高性能角度和減少服務器部署的角度考慮，推薦採用Lighttpd HTTP服務器，而不是採用傳統的Apache服務器，原因是Apache使用阻塞模式的I/O操作，性能相對較差，併發能力有限，而Lighttpd使 用異步I/O方式，處理資源下載的併發能力遠遠超過Apache。
1.5 流媒體服務應用
流媒體主要應用在視頻會議、視頻點播、遠程教育、在線直播等方面，這類應用主要的性能瓶頸是網絡帶寬和存儲系統帶寬（主要是讀操作），面對海量用戶，如何保障用戶接收到高清晰的、流暢的畫面，如何最大限度地節省網絡帶寬，這些都是流媒體應用要解決的首要問題。
對 於流媒體服務器的優化，可以從存儲策略、傳輸策略、調度策略、代理服務器緩存策略及流媒體服務器的體系結構設計等幾個方面進行考慮。在存儲方面，需要對視 頻的編碼格式進行優化，進而節省空間，優化存儲性能；在傳輸方面，可以採用智能流技術控制發送的速率，最大程度保障用戶觀看視頻的流暢性；在調度方面，可 以採用靜態調度和動態調度結合的方法；在代理服務器方面，可以採用分段緩存、動態緩存等管理策略；在流媒體體系結構方面，可以採用內存池和線程池技術改善 內存消耗和線程過多對性能造成的影響。