之前寫過一篇性能測試新手誤區（五）：這是性能問題么，主要講一個有效的性能問題應該是什么樣的，其中提到了定位的問題。但是那篇文章只說了WHAT，并沒有說HOW，只說tester要有明確的定位，卻沒提如何才能定位。實際工作中，我也總是接到這種問題，所以還是要寫一篇關于方法的文章，來說說HOW TO DO。
以一個典型的WEB系統來舉例，性能問題一般體現在客戶端請求后的響應時間上。在性能測試過程中，即壓力增大到某個程度后，響應時間指標迅速增長。但如那篇文章所說，這只能叫做一個現象，測試人員需要找到問題所在，HOW TO DO？
首先要搞清楚，客戶端從發出請求直到看到最終結果，共經歷了哪些過程。如果繪制出一張完整的路徑圖，我們的問題必將定位到這張圖中的某一點上。下面是我畫的一個常見的WEB系統請求的流轉過程。
客戶發出一個請求，這個請求首先會到達中間件的監聽端口，專門的監聽線程負責接待它，并將它分配給一個空閑的HTTP處理線程。HTTP線程根據請求內容，去執行相應的程序代碼，這里會涉及程序的內部資源，比如專用的線程、一些隊列等，程序的內部也許還有多個組件，依然可以拆分。再往后，從中間件維護的數據庫連接池中取出一個空閑連接，通過它來與數據庫進行交互。數據庫收到查詢請求后，同樣需要找到一個可用的執行線程，然后才能執行具體的SQL，這里又會牽扯到很多數據庫的內部資源，如鎖、緩存等等。
可以看到，從用戶點擊鼠標發出請求，到顯示器上展現出結果，實際是經過了很多處理過程的，這里的每一個節點出現問題，都會導致我們最終看到的“響應慢”現象出現（這里不考慮操作系統層面、網絡層面等一些外層的因素）。
理解了這個過程，只需采取一些科學的方法即可逐漸逼近問題根源，那就是層層剝離、不斷排除。從實際經驗來看，數據庫端最容易出問題，那么首先就要對其進行驗證。數據庫的性能一般是直接體現在SQL的執行效率上，我們可以捕獲到出現問題時所有執行過的SQL，看其耗時是否正常。如果判斷數據庫端沒有問題，那么再來到中間件端，這里又可分為應用服務器本身和我們自己的程序，可以先看看最容易驗證的部分，應用服務器本身通常維護了一些線程池，很容易可以觀察到它們的使用情況，如果這里沒有發現異常，那么問題很可能就出現在我們程序的代碼內部。如果在某一點上發現了異常現象，不要急于斷定這里就是問題根源，而是要同時觀察與之相鄰節點的表現，一個節點的故障通常也會導致另一節點的異常。
一個很有效的排查手段就是日志，在每一個節點上輸出接收到的請求和處理結果的日志，通常都會很容易的發現問題。
大致思路就是這樣，總結起來其實很簡單。一是要理解請求處理的完整流程，二是通過科學合理的方法去分析。
最后推薦個比較典型的問題排查過程供大家體會，超級奇怪的“黑色10秒鐘”。我自己也有一些這種很有代表性的分析過程，有時間整理好也貼上來。