轉自： http://www.cnblogs.com/fnng/archive/2013/03/19/2970315.html   作者：蟲師

最近一直糾結效能分析與調優如何下手，先從硬體開始，還是先從程式碼或資料庫。從作業系統（CPU排程，記憶體管理，程序排程，磁碟I/O）、網路、協議（HTTP， TCP/IP ），還是從應用程式程式碼，資料庫調優，中介軟體配置等方面入手。

　　單一箇中間件又分web中介軟體（apache 、IIS），應用中介軟體（tomcat 、weblogic 、webSphere ）等，雖然都是中介軟體，每一樣拎出來往深了學都不是一朝一夕之功。但調優對於每一項的要求又不僅僅是“知道”或“會使用”這麼簡單。起碼要達到“如何更好的使用”。

　　常看到效能測試書中說，效能測試不單單是效能測試工程師一個人的事兒。需要DBA 、開發人員、運維人員的配合完成。但是在不少情況下效能測試是由效能測試人員獨立完成的，退一步就算由其它人員的協助，瞭解系統架構的的各個模組對於自身的提高也有很大幫助，同進也更能得到別人的尊重。

　　再說效能調優之前，我們有必要再提一下進行測試的目的，或者我們進行效能測試的初衷是什麼？

能力驗證：驗證某系統在一定條件具有什麼樣的能力。

能力規劃：如何使系統達到我們要求的效能能力。

應用程式診斷：比如記憶體洩漏，通過功能測試很難發現，但通過效能測試卻很容易發現。

效能調優：滿足使用者需求，進一步進行系統分析找出瓶頸，優化瓶頸，提高系統整體效能。

一般系統的瓶頸                                                                                          

效能測試調優需要先發現瓶頸，那麼系統一般會存在哪些瓶頸：

硬體上的效能瓶頸：

一般指的是CPU、記憶體、磁碟I/O 方面的問題，分為伺服器硬體瓶頸、網路瓶頸（對區域網可以不考慮）、伺服器作業系統瓶頸（引數配置）、中介軟體瓶頸（引數配置、資料庫、web伺服器等）、應用瓶頸（SQL 語句、資料庫設計、業務邏輯、演算法等）。

應用軟體上的效能瓶頸：

一般指的是應用伺服器、web 伺服器等應用軟體，還包括資料庫系統。

例如：中介軟體weblogic 平臺上配置的JDBC連線池的引數設定不合理，造成的瓶頸。

應用程式上的效能瓶頸：

一般指的是開發人員新開發出來的應用程式。

例如，程式架構規劃不合理，程式本身設計有問題（序列處理、請求的處理執行緒不夠），造成系統在大量使用者方位時效能低下而造成的瓶頸。

作業系統上的效能瓶頸：

一般指的是windows、UNIX、Linux等作業系統。

例如，在進行效能測試，出現實體記憶體不足時，虛擬記憶體設定也不合理，虛擬記憶體的交換效率就會大大降低，從而導致行為的響應時間大大增加，這時認為作業系統上出現效能瓶頸。

網路裝置上的效能瓶頸：

一般指的是防火牆、動態負載均衡器、交換機等裝置。

例如，在動態負載均衡器上設定了動態分發負載的機制，當發現某個應用伺服器上的硬體資源已經到達極限時，動態負載均衡器將後續的交易請求傳送到其他負載較輕的應用伺服器上。在測試時發現，動態負載均衡器沒有起到相應的作用，這時可以認為網路瓶頸。

　　效能測試出現的原因及其定位十分複雜，這裡只是簡單介紹常見的幾種瓶頸型別和特徵，而效能測試所需要做的就是根據各種情況因素綜合考慮，然後協助開發人員\DBA\運維人員一起定位效能瓶頸。

一般效能調優步驟                                                                                      

一般效能問題調優的步驟：

步驟一：確定問題

應用程式程式碼：在通常情況下，很多程式的效能問題都是寫出來的，因此對於發現瓶頸的模組，應該首先檢查一下程式碼。

資料庫配置：經常引起整個系統執行緩慢，一些諸如oracle 的大型資料庫都是需要DBA進行正確的引數調整才能投產的。

作業系統配置：不合理就可能引起系統瓶頸。

硬體設定：硬碟速度、記憶體大小等都是容易引起瓶頸的原因，因此這些都是分析的重點。

網路：網路負載過重導致網路衝突和網路延遲。

步驟二：確定問題

　　當確定了問題之後，我們要明確這個問題影響的是響應時間吞吐量，還是其他問題？是多數使用者還是少數使用者遇到了問題？如果是少數使用者，這幾個使用者與其它使用者的操作有什麼不用？系統資源監控的結果是否正常？CPU的使用是否到達極限？I/O 情況如何？問題是否集中在某一類模組中？ 是客戶端還是伺服器出現問題？ 系統硬體配置是否夠用？實際負載是否超過了系統的負載能力？ 是否未對系統進行優化？

通過這些分析及一些與系統相關的問題，可以對系統瓶頸有更深入的瞭解，進而分析出真正的原因。

步驟三： 確定調整目標和解決方案

得高系統吞吐理，縮短響應時間，更好地支援併發。

步驟四：測試解決方案

對通過解決方案調優後的系統進行基準測試。（基準測試是指通過設計科學的測試方法、測試工具和測試系統，實現對一類測試物件的某項效能指標進行定量的和可對比的測試）

步驟五：分析調優結果

系統調優是否達到或者超出了預定目標？系統是整體效能得到了改善，還是以系統某部分效能來解決其他問題。調優是否可以結束了。

　　最後，如果達到了預期目標，調優工作就基本可以結束了。

下面算是一個技巧，如面試官問到一個性能問題假設，我不知道效能問題出在哪兒時，可以按照這個思路回答^_^

   • 查詢瓶頸時按以下順序，由易到難。
    伺服器硬體瓶頸---〉網路瓶頸（對區域網，可以不考慮）---〉伺服器作業系統瓶頸（引數配置）---〉中介軟體瓶頸（引數配置，資料庫，web伺服器等）---〉應用瓶頸（SQL語句、資料庫設計、業務邏輯、演算法等）
    注：以上過程並不是每個分析中都需要的，要根據測試目的和要求來確定分析的深度。對一些要求低的，我們分析到應用系統在將來大的負載壓力（併發使用者數、資料量）下，系統的硬體瓶頸在哪兒就夠了。
    • 分段排除法 很有效

效能測試調優應該注意的要點：

• 要點1： 在應用系統的設計開發過程中，應始終把效能放在考慮的範圍內。
• 要點2： 確定清晰明確的效能目標是關鍵。
• 要點3： 必須保證調優後的程式執行正確。
• 要點4： 系統的效能更大程度上取決於良好的設計，調優技巧只是一個輔助手段。
• 要點5： 調優過程是迭代漸進的過程，每一次調優的結果都要反饋到後續的程式碼開發中去。
• 要點6： 效能調優不能以犧牲程式碼的可讀性和可維護性為程式碼。

　　本文只介紹了一些效能調優的要關注的東西以及效能調優的一般要點。並沒有具體說如何對系統的每個部件進行調優，如何要細說也不是一兩書能說清的，對知識面的要求也非常高，是我目前的能力無法觸控的。

這裡做個總結：

　　《效能測試知多少》系列基本完結，雖然時間拉得比較長，但我沒有把它給太監。雖然內容都在空談效能測試理論知識，但我認為這些東西對於你從事效能測試工作必不可少。當然，我在“ jmeter基礎 ” 與“ loadrunner 技巧 ” 中講解兩個效能測試工具的使用。

　　如果我的這些文章對於想了解和學習效能的同學帶來一絲的幫助，我將非常開心。我不是高手，只是和你一起熱愛測試技術的初學者，只是比較喜歡總結；也時常為前途迷茫，但我知道只要斷去學習，路就在前方。我後面會整理效能調優的相關文章。

效能測試所有文章彙總：http://www.cnblogs.com/fnng/archive/2012/08/17/2644878.html