陸續聊了性能測試指標和性能測試排查過程也有四五篇文章了，今天分享一個真實的性能測試真案例。
在一次某銀行項目性能測試中，當系統運行到1個小時10分左右：tps出現明顯下降,響應時間明顯上升，其他相關業務cpu、內存、網絡等各項指標都正常；此問題一直重複出現，而且在銀行測試環境和公司測試環境一直存在。
通過分析懷疑可能是以下原因造成的
1.定時任務，
2.測試代碼，
3.業務代碼，
4.FGC。
然後就根據猜想一項一項測試驗證。
1.停掉所有定時任務，和開發確認沒有段時間插入定時日誌或者其他數據庫操作。
2.檢查測試代碼，測試代碼和正確的測試代碼只有很少的幾行差異，而且全部是http連接規範的寫法，不至於有問題。
3.業務代碼，檢查所有業務日誌，tomcat日誌，jstack抓trace等，都未見異常。
4. Full GC 通過抓jstat信息，發現在50分左右確實出現fgc如圖：
但在相同時間，該接口的TPS有少量下降， 不是原來遇到的大量下降，如圖
故排除fgc問題。貌似再次測試進入死衚衕，再次懷疑此應用代碼問題。
就在早上突然想到是不是負載均衡工具有問題？？？？到公司迫不及待的測試下。
通過測試，去掉負載haproxy代理，自己寫了一個隨機分配到四個應用節點地址，通過三個小時測試，沒有出現上述怪異的問題。
告誡各位，在性能測試時，特別要小心軟負載工具的應用，對性能測試的影響， haproxy工具坑我好幾次了，使用時一定要小心。
2019年連續第五十八天修心 土司於北京