1、着手在測試前：理清資料流向，資料流程分解 通過繪制資料流向圖，以便清晰的列出所有可能出現瓶頸的位置，避免在分析過程中遺漏可能的瓶頸點。 系統架構分解——水池模型 要查找瓶頸，首先要對系統的架構有詳細的了解，清楚知道所有可能成為瓶頸的位置。隻有這樣才能在遇到問題是合理的設計 測試用例，對流程的各個步驟進行逐一排查。 舉個例子，家裡廚房的水池下水堵了，我們要找原因，首先得知道水池的下水道都有哪些部分：
簡單的看，可以把下水道分解為水漏、上連接配接管、回水彎、下連接配接管最後接入地漏。再查找堵塞位置時，我們就可以将水直接導入回水彎，排除水漏和上連接配接管道堵塞的可能。 應用在測試中，我們也可以利用直接向應用中間件發請求，來排除Web代理層的瓶頸。 通過繪制流向圖，可以更清晰的展現系統中資料流向，幫助我們在定位瓶頸的過程始終能迅速的分析預計到下一個可能的瓶頸位置。
如上圖，就是在play一個Mobile game時的資料流向圖。 2、最直覺的指征：檢索日志中的異常 日志是系統異常的最直接反映，通過用戶端(負載工具端)、伺服器端的日志，可以迅速确定瓶頸可能存在的方向。一些在大使用者量大并發情況下的功能問題，也會在錯誤日志中展現。 在 性能測試過程中，一般情況是不把全部日志打開的，而是盡量保持與生産環境的設定相同，生産環境開啟什麼樣的日志級别，在性能測試環境中也應該開啟同樣的級别。 但是往往在生産環境出于性能考慮，并不會把日志級别開的非常高，是以在發現系統存在性能問題時，我們可以适當調高日志級别，以便獲得更多的資訊。 在日志中，我們可以由一些關鍵字直接推斷出系統的問題所在，比如： · Too many open files Linux下存在句柄數限制，系統的預設值較小，在測試前應該優化，另外還要懷疑是否程式存在打開句柄卻在某些情況下沒有關閉。 · OutOfMemoryError/Cannot allocate memory Java環境的虛拟記憶體異常，往往需要關注是否有溢出。 · SQLException 資料庫語句執行異常，一般日志中還會有資料庫傳回的資訊。 · Connection closed/connection refused 連接配接被關閉被拒絕，一般是連接配接數限制不能承擔目前的壓力。 3、最底層的反映：分析硬體資源占用 硬體資源也是系統性能達到瓶頸點的重要指征，如果沒有在日志中找到異常，那麼通過監控硬體資源消耗，往往可以發現系統的資源瓶頸。 3.1 CPU占用率 CPU的高占用，并不一定表示有問題，因為實作最優性能的一方面就是充分發揮目前的硬體資源能力。
但是如上圖這樣CPU長期出于滿負荷，就很值得我們關注，至少說明在大多數情況下，系統已經是在耗用最大的計算能力進行計算，運算能力已經成為瓶頸。 另外還要注意CPU是消耗在User還是Sys還是Wait, 如果是Wait，還要觀察其他硬體資源，檢視CPU是在等待什麼。 3.2 記憶體占用 記憶體在性能測試中是被重點關注的名額，因為它是反映重大缺陷——記憶體洩露的最直接名額，但是我們應該注意到，在JAVA架構中的記憶體洩漏是發生在虛拟記憶體中的。 觀察記憶體/虛拟記憶體的占用情況，尤其是在壓力消失後的記憶體占用恢複情況，是比較直接的判斷記憶體洩漏的依據。
如果觀察到如上圖的記憶體使用情況，在每次Full GC後，占用的記憶體都沒能恢複到原來的水準，如果在壓力撤除一段時間後，記憶體依舊不能恢複，那麼十有八九目前系統存在記憶體洩漏。 3.3 磁盤I/O 通常情況下，磁盤是計算機中速度最慢的一個子系統，是以很多情況中，磁盤I/O會成為系統的瓶頸。實際上在設計高性能系統的時候，會把避免磁盤I/O作為一個首要準則。 雖然目前的技術發展讓存儲系統的讀寫速度不斷提升，但高昂的成本使得大多數情況下，高速存儲會使用在資料庫或檔案伺服器上，而不會使用在應用伺服器中。是以在我們進行性能測試時，要更多的注意應用伺服器的磁盤使用情況。 3.4 網絡I/O 很多時候大家都容易忽略網絡對系統的影響，實際上網絡帶寬在一些情況下也會成為系統的瓶頸。一旦在業務的請求和響應中包含較大的資料傳輸時，往往會遇到網絡瓶頸。因為更多的時候伺服器采用的還是以太網卡，1000M網卡在全雙工模式下傳輸速率也隻有80M/s，如果響應中包含報表、圖檔之類的大尺寸資料，很有可能在性能測試中出現網絡瓶頸。 還有一點就是不要忽略回環位址傳輸的影響，比如一些應用通路本地監聽的其他服務，都會受到網卡的傳輸速率限制的影響。 4、軟體性能軟肋：資料庫的監控分析 對于Web系統，超過七成的瓶頸都出現在資料庫子系統，是以在進行之前幾步不能明确瓶頸位置的時候，應優先進行資料庫的監控分析。 Oracle資料庫監控工具 Oracle本身提供了ASH，AWR等Report來幫助進行性能分析，但是對于測試人員來說，掌握這些需要較深入的資料庫知識學習，不是一朝一夕可以達成的。而一些第三方提供的工具，通過圖形界面，可以更加直覺的幫助我們進行Oracle資料庫的監控和分析。 Lab128就是國内開發的一塊很不錯的共享軟體，而且它還提供無限期的試用key，可以免費試用。 Oracle中的等待事件 判斷Oracle中的瓶頸，了解Oracle中的等待事件Wait event，對于查找瓶頸有很大的幫助。在Oracle中，處理SQL的過程，會産生一系列的等待事件。 有等待事件并不代表資料庫存在瓶頸，正常的處理也會有等待事件，但如果發現等待事件激增，或者SQL執行緩慢，這時候等待事件中排名靠前的事件将會直接反映出瓶頸所在。
上圖是在測試中的某一時刻，log sync的等待事件突然增高，同時資料庫的吞吐率大幅下降，原本正常的SQL執行速度也突然變長。 因為壓力并沒有突然改變，很有可能是寫log的過程出現了問題，或者是在傳輸過程，或者是在存儲子系統。後來經過排查，發現是存儲叢集的一個存儲單元出現故障導緻寫入速度變慢緻使出現大量等待。 5、最後的大殺器：應用伺服器監控及代碼分析 如果沒能在其他位置發現瓶頸，那麼軟體程式所運作的平台——應用伺服器很可能是最大的潛在瓶頸點，進行應用伺服器的監控與分析将是我們最後的大殺器。 5.1 常見的軟體資源種類 相對于硬體資源，軟體資源往往容易被忽略，它不像CPU占用率那麼讓人更直覺的和性能聯系起來，但是實際上，軟體資源同樣限制着軟體系統能達到什麼樣的性能。 軟體資源不論是在Web層，應用層還是在資料庫層，都可以按“入口”、“内部”、“出口”來劃分。對于常見的原因中間件，“入口”就是如HTTP連接配接池之類，是資料來源方向的相關設定，比如連接配接數限制，逾時時間，連接配接回收政策等等；“内部”就是處理請求的各項資源，不如線程數，線程排程政策，虛拟記憶體設定，GC政策等等；“出口”則是向後端互動的各項資源，如資料庫連接配接池的配置。 5.2 應用中間件監控 要了解軟體資源是否成為瓶頸，我們就需要監控這些軟體資源名額。以JAVA環境為例，Weblogic 本身就有控制台，提供了各種計數器。
上圖顯示的是Execute Threads的計數器，對請求的處理就在這些Thread中進行。 Tomcat也有開源的控制台，常用的像PSI-Probe，提供了Tomcat伺服器各項資源的圖形化監控。如下圖中對JVM的監控。
5.3 應用中間件剖析 僅僅監控隻能初步判斷問題的方向，例如發現ExecuteThreads持續的增加，我們雖然知道這個現象不正常，但是想要确定是程式中的哪個方法導緻了目前問題，我還需要其他的工具進行深入剖析。 對于Java程式，最常用的工具有JProfiler，YourKit，他們的原理類似，都是要把一個小插件挂在到應用伺服器上，以擷取需要的程式運作資訊。 而Sun在JDK1.7後版本整合了繼承自JRockit的MissionControl，也提供了很強大的分析監控功能，而且開銷較小，确實是個不錯的選擇。 它提供的Mem leak detector可以對對象的建立進行趨勢分析，幫你找到最有可能出現洩漏的對象，
再通過展開剖析工具中的invoke tree，找出建立該對象的方法，可以更細緻的定位問題的原因。
同時，Call tree 也可以依據CPU時間進行分析，找到在虛拟機中消耗最高的方法。 轉載：http://www.51testing.com/html/03/n-3649003-2.html