性能測試常見瓶頸分析及調優方法

在性能測試過程當中，最重要的一部分就是性能瓶頸定位與調優。而引起性能瓶頸的緣由是多種多樣的，在以前的博客：常見的性能測試缺陷有進行介紹。

這篇博客，來聊聊性能測試過程當中的一些注意事項，以及常見的一些性能缺陷表現及如何進行定位分析而且調優。。。

 

1、注意事項

一、斷言

在壓測時，爲了判斷髮送的請求是否成功，通常會經過對請求添加斷言來實現。使用斷言時，建議遵循以下規範：

①、斷言內容儘可能以status/code、msg/message來判斷（固然前提是接口設計遵循Restful規範）

Jmeter示例：

阿里雲PTS：

若是使用的是PTS壓測，則斷言設置中，以code/status、msg/message等於對應的值爲準；

②、儘量不要將全部的Response Body內容做爲斷言判斷的內容，這樣極可能會致使大量的「斷言」失敗；

PS：而後很遺憾的是，見過不少作壓測的童鞋，斷言內容以整個響應參數內容作斷言，致使大量的報錯。

二、成功率

通常在性能測試中，咱們都追求99.99%的成功率，但在實際的測試過程當中，爲了儘量覆蓋代碼邏輯，在準備階段會盡量的準備較多的熱點數據去作到覆蓋。

這樣的話，咱們所關注的成功率指標，就要分爲以下兩種：

①、事務成功率

事務成功率在某些時候也能夠視爲請求成功率，在斷言判斷時以code/status等內容來做爲請求是否成功的衡量依據；

②、業務成功率

實際的業務場景中，所謂的成功率，並不能僅根據返回的code/status來判斷。好比：一個查詢請求，不管是返回正確的查詢結果仍是因爲對應數據返回空，這個請求都是成功的。

對應的響應參數多是： {"status":"200","message":"success"} ；也多是： {"status":"200","message":"暫無對應結果"} 。

PS：在性能測試過程當中，考慮到業務成功率和請求成功率的不一樣指標，結合斷言內容，須要靈活設置斷言的方式（固然，我依然建議遵循如上的2點斷言規範）！

 

2、常見性能瓶頸解析及調優方案

在性能測試中，致使性能出現瓶頸的緣由不少，但經過直觀的監控圖表現出來的樣子，根據出現的頻次，大概有以下幾種：

性能瓶頸出現頻次	具體表現
高	TPS波動較大
高	高併發下大量報錯
中	集羣類系統，各服務節點負載不均衡
中	併發數不斷增長，TPS上不去，CPU耗用不高
低	壓測過程當中TPS不斷降低，CPU使用率不斷下降

下面對常見的幾種性能瓶頸緣由進行解析，並說說常見的一些調優方案：

一、TPS波動較大

緣由解析：出現TPS波動較大問題的緣由通常有網絡波動、其餘服務資源競爭以及垃圾回收問題這三種。

性能測試環境通常都是在內網或者壓測機和服務在同一網段，可經過監控網絡的出入流量來排查；

其餘服務資源競爭也可能形成這一問題，能夠經過Top命令或服務梳理方式來排查在壓測時是否有其餘服務運行致使資源競爭；

垃圾回收問題相對來講是最多見的致使TPS波動的一種緣由，能夠經過GC監控命令來排查，命令以下：

1 # 實時打印到屏幕
2 jstat -gc PID 300 10
3 jstat -gcutil PID 300 10
4 # GC信息輸出到文件
5 jstat -gc PID 1000 120 >>/path/gc.txt
6 jstat -gcutil PID 1000 120 >>/path/gc.txt

調優方案：

網絡波動問題，可讓運維同事協助解決（好比切換網段或選擇內網壓測），或者等到網絡較爲穩定時候進行壓測驗證；

資源競爭問題：經過命令監控和服務梳理，找出壓測時正在運行的其餘服務，經過溝通協調中止該服務（或者換個沒資源競爭的服務節點從新壓測也能夠）；

垃圾回收問題：經過GC文件分析，若是發現有頻繁的FGC，能夠經過修改JVM的堆內存參數Xmx，而後再次壓測驗證（Xmx最大值不要超過服務節點內存的50%！）

二、高併發下大量報錯

緣由解析：出現該類問題，常見的緣由有短鏈接致使的端口被徹底佔用以及線程池最大線程數配置較小及超時時間較短致使。

調優方案：

短鏈接問題：修改服務節點的tcp_tw_reuse參數爲1，釋放TIME_WAIT scoket用於新的鏈接；

線程池問題：修改服務節點中容器的server.xml文件中的配置參數，主要修改以下幾個參數：

# 最大線程數，即服務端能夠同時響應處理的最大請求數
maxThreads="200"                        
# Tomcat的最大鏈接線程數，即超過設定的閾值，Tomcat會關閉再也不須要的socket線程 
maxSpareThreads="200"               
# 全部可用線程耗盡時，可放在請求等待隊列中的請求數，超過該閾值的請求將不予處理，返回Connection refused錯誤
acceptCount="200"                 
# 等待超時的閾值，單位爲毫秒，設置爲0時表示永不超時
connectionTimeout="20000"         

三、集羣類系統，各服務節點負載不均衡

緣由解析：出現這類問題的緣由通常是SLB服務設置了會話保持，會致使請求只分發到其中一個節點。

調優方案：若是確認是如上緣由，可經過修改SLB服務（F5/HA/Nginx）的會話保持參數爲None，而後再次壓測驗證；

四、併發數不斷增長，TPS上不去，CPU使用率較低

緣由解析：出現該類問題，常見的緣由有：SQL沒有建立索引/SQL語句篩選條件不明確、代碼中設有同步鎖，高併發時出現鎖等待；

調優方案：

SQL問題：沒有索引就建立索引，SQL語句篩選條件不明確就優化SQL和業務邏輯；

同步鎖問題：是否去掉同步鎖，有時候不只僅是技術問題，還涉及到業務邏輯的各類判斷，是否去掉同步鎖，建議和開發產品同事溝通確認；

五、壓測過程當中TPS不斷降低，CPU使用率不斷下降

緣由解析：通常來講，出現這種問題的緣由是由於線程block致使，固然不排除其餘可能；

調優方案：若是是線程阻塞問題，修改線程策略，而後從新驗證便可；

六、其餘

除了上述的五種常見性能瓶頸，還有其餘，好比：connection reset、服務重啓、timeout等，固然，分析定位後，你會發現，咱們常見的性能瓶頸，

致使其的緣由大多都是由於參數配置、服務策略、阻塞及各類鎖致使。。。

性能瓶頸分析參考準則：從上至下、從局部到總體！

 

以上分析及調優方案僅供參考，具體定位還須要根據日誌監控等手段來分析調優。。。