"資料庫
（或中介軟體）非常慢了，如何監控它的效能」
「你想得到什麼效能指標？」
「就是……內部的效能指標」
收到效能測試人員這樣的問題後，通常會發生上面的對話。
我的觀點是，準確的說出你想要做什麼，比你會不會做更重要。
那麼對於效能測試人員來說，」效能監控「這門必修課，該從何下手呢？
監控什麼
如果我給你乙個黑盒子，告訴你裡面是一部機器，要監控它的效能。你能做到麼？當然不能。因為你不知道這部機器如何執行，你不知道對它而言效能是什麼。
效能測試也一樣，說到作業系統，大家都知道效能指標要看cpu、memory、disk io以及network等等。但是到了資料庫和中介軟體，如果測試人員說不出具體內容，這表明他不知道針對這個物件，效能是什麼，即便把最完整的效能指標擺在面前，恐怕也是沒有意義的。
當然知識和經驗是一步步積累起來的，但也需要測試人員去主動的學習。從系統體系結構、執行原理到效能監控、效能調優基礎和方法，官方手冊總是最好的教材。
那麼在沒有掌握這些知識之前，我希望上面的問題是這樣問，「資料庫（或中介軟體）非常慢了，一般需要監控它的哪些效能指標呢」，得到回答後趕緊翻資料吸收相關的知識。
過程中的監控
效能測試新手容易忽略測試過程中的效能監控，而只給出乙個最終的測試執行結果。
比如這個問題，「測試執行3小時後，系統沒有響應，中介軟體無法連線」。
對於這樣的問題，期望開發人員如何處理呢？中介軟體已經無法連線，想獲取到一些內部的效能指標恐怕都已做不到。只有重執行一次，讓開發人員來關注過程中的執行狀況，但這本應是由測試人員來做的。
如果我們知道，中介軟體本身無法響應一般可能是因為這兩個問題：
jvm堆記憶體用滿，不停的進行gc，導致響應超慢（但是還沒有oom，否則就報錯了）
處理http請求的執行緒，都被占用或者鎖住
那麼我們就可以在測試過程中去監控這兩項資料，跟蹤變化趨勢，直到系統再次無法響應。如果正好其中的乙個資源也耗盡了，那麼就可以確認「無法響應「這個現象的直接原因。實際上，這兩個指標基本也是中介軟體最重要的指標，理應每次測試過程都進行監控和資料採集了。
監控的層次
系統的效能表現會涉及到多個層面，比如：
中介軟體 -> 中介軟體作業系統 -> 資料庫 -> 資料庫作業系統 -> 客戶端
監控時也要著眼於多個層面，這樣才有可能更接近問題的本質。還是上面那個中介軟體無法響應的問題，假設我們觀察到了所有http執行緒都被占用，也許更進一步我們又會發現這些執行緒都在執行資料庫的查詢，而這些查詢在資料庫中的狀態依然是running，那就說明更根本的原因是在資料庫層面。這也就是問題的逐步定位。
全面的監控
片面的資料不足以說明問題，系統的方方面面常常是相互影響的。
比如資料庫的cpu占用很高，並不能證明系統是計算密集型、cpu是瓶頸，也有可能是spinlock的爭用導致了cpu驟增。
再比如大量的page-in io可能會使記憶體出現瓶頸。
上面的層次問題其實也屬於」全面「的範圍。只有拿到全面的資料，才有可能分析出正確的結論。
當然，這又是乙個需要積累的過程，如果連spinlock都不知道，又怎麼可能有準確的判斷呢。
方法還是乙個，主動的學習，系統的學習。
效能測試新手常犯錯誤總結（七） 你需要調優麼
測試人員喜歡在得到某個達不到預期的效能結果後，進行一下 調優 pm有時也會布置任務，測試完成後 調乙個優 一些人貌似有了這種觀念 調優才使效能測試有意義 效能測試的目的就是調優 做調優才能顯出測試人員的水平 隨著經驗的增長和對效能更深入的認識，我越來越體會到調優是乙個複雜的過程，不是動動嘴 改倆個引...
電子郵件營銷常犯錯誤總結
郵件營銷已被證明是不可或缺的營銷工具，它能讓您的產品和服務資訊直接傳送到客戶手中,而掌握了正確的郵件營銷策略，能讓您的營銷效果獲得更大的提公升。但在平時的電子郵件營銷中，營銷人員可能會犯以下幾點錯誤 目標物件不準確 花大量時間找預客戶的郵寄位址和電子郵件位址，在並不了解目標物件做什麼的情況下，盲目傳...
Python之def使用常犯錯誤總結
定義乙個重量轉換函式，輸入值為以 g 為單位，返回以 kg 的結果。個人常犯錯誤如下 1 缺少冒號 def weight converter g weight g 100 return str weight kg print weight converter 5005 報錯資訊 syntaxerro...