1、 基於動態內容爲主的網站優化案例
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進行讀寫分離部署,這樣一套高性能、高可靠的網站系統就構建起來了。
2、 基於動態、靜態內容結合的網站優化案例
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服務器,網站的總體性能會有一個質的提高。服務器