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作為一個首要準則。 　　雖然當前的技術發展讓儲存系統的讀寫速度不斷提升，但高昂的成本使得大多數情況下，高速儲存會使用在資料庫或檔案伺服器上，而不會使用在應用伺服器中。所以在我們進行效能測試時，要更多的注意應用伺服器的磁碟使用情況。