系列原創：性能測試新手誤區
“數據庫（或中間件）非常慢了，如何監控它的性能”
“你想得到什么性能指標？”
“就是……內部的性能指標”
收到性能測試人員這樣的問題后，通常會發生上面的對話。
我的觀點是，准確的說出你想要做什么，比你會不會做更重要。
那么對於性能測試人員來說，”性能監控“這門必修課，該從何下手呢？
監控什么
如果我給你一個黑盒子，告訴你里面是一部機器，要監控它的性能。你能做到么？當然不能。因為你不知道這部機器如何運行，你不知道對它而言性能是什么。
性能測試也一樣，說到操作系統，大家都知道性能指標要看CPU、MEMORY、DISK IO以及NETWORK等等。但是到了數據庫和中間件，如果測試人員說不出具體內容，這表明他不知道針對這個對象，性能是什么，即便把最完整的性能指標擺在面前，恐怕也是沒有意義的。
當然知識和經驗是一步步積累起來的，但也需要測試人員去主動的學習。從系統體系結構、運行原理到性能監控、性能調優基礎和方法，官方手冊總是最好的教材。
那么在沒有掌握這些知識之前，我希望上面的問題是這樣問，“數據庫（或中間件）非常慢了，一般需要監控它的哪些性能指標呢”，得到回答后趕緊翻資料吸收相關的知識。
過程中的監控
性能測試新手容易忽略測試過程中的性能監控，而只給出一個最終的測試運行結果。
比如這個問題，“測試運行3小時后，系統沒有響應，中間件無法連接”。
對於這樣的問題，期望開發人員如何處理呢？中間件已經無法連接，想獲取到一些內部的性能指標恐怕都已做不到。只有重運行一次，讓開發人員來關注過程中的運行狀況，但這本應是由測試人員來做的。
如果我們知道，中間件本身無法響應一般可能是因為這兩個問題：
JVM堆內存用滿，不停的進行GC，導致響應超慢（但是還沒有OOM，否則就報錯了）
處理HTTP請求的線程，都被占用或者鎖住
那么我們就可以在測試過程中去監控這兩項數據，跟蹤變化趨勢，直到系統再次無法響應。如果正好其中的一個資源也耗盡了，那么就可以確認“無法響應“這個現象的直接原因。實際上，這兩個指標基本也是中間件最重要的指標，理應每次測試過程都進行監控和數據采集了。
監控的層次
系統的性能表現會涉及到多個層面，比如：
中間件 -> 中間件操作系統 -> 數據庫 -> 數據庫操作系統 -> 客戶端
監控時也要着眼於多個層面，這樣才有可能更接近問題的本質。還是上面那個中間件無法響應的問題，假設我們觀察到了所有HTTP線程都被占用，也許更進一步我們又會發現這些線程都在執行數據庫的查詢，而這些查詢在數據庫中的狀態依然是running，那就說明更根本的原因是在數據庫層面。這也就是問題的逐步定位。
全面的監控
片面的數據不足以說明問題，系統的方方面面常常是相互影響的。
比如數據庫的CPU占用很高，並不能證明系統是計算密集型、CPU是瓶頸，也有可能是spinlock的爭用導致了CPU驟增。
再比如大量的page-in IO可能會使內存出現瓶頸。
上面的層次問題其實也屬於”全面“的范圍。只有拿到全面的數據，才有可能分析出正確的結論。
當然，這又是一個需要積累的過程，如果連spinlock都不知道，又怎么可能有准確的判斷呢。
方法還是一個，主動的學習，系統的學習。