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