你真的了JMeter解聚合報告麼？

1.背景

你們在使用JMeter進行性能測試時，聚合報告(Aggregate Report)能夠說是必用的監聽器，可是你真的瞭解聚合報告麼？

2.目的

本次筆者跟你們聊聊聚合報告(Aggregate Report)經常使用誤區。

3.常見誤區

說明：本次筆者採用的JMeter版本爲5.1.1

• 誤區一：90%、95%、99百分位的理解

常常有的同窗理解成平均90%、95%、99%請求的交易耗時，包括一些作了好久的老測人員試居然也是這麼理解的（其實筆者最開始也是這麼理解的），出現這個問題根本緣由是對百分位的概念理解錯誤（換句話說：你數學是體育老師教的吧！），那麼正確該怎麼理解呢？

咱們來看一張聚合報告圖：

正解：90%百分位值爲230ms，在發送100筆請求過程當中，聚合報告會實時給請求耗時進行由小到大行排序，排序後的第90個請求耗時爲230ms，也就是說前90筆請求中耗時最長的是230ms（其他90%百分位，95%百分位道理相似就不佔篇贅述了），聚合報告平均值要與百分位值結合來看。

說明：90%、95%、99%值是支持自定義在jmeter.properties修改：

• 誤區二：把吞吐量值當TPS值

常常有的同窗直接把聚合報告中的吞吐量看成TPS來看（網上還有一種說法是把請求放在事務控制器裏，吞吐量就能夠當作TPS，經筆者驗證並不能夠）,這種作法是至關不嚴謹的。那麼聚合報告中的吞吐量什麼狀況下能夠當作TPS?

老規矩仍是用實際操做來驗證：

沒錯，仍是上面聚合報告的圖，筆者把100.jtl文件中的請求所有改爲false,再來看下聚合報告結果：

而後再用聚合報告打開100.jtl結果文件，聚合報告各項數據沒有任何改變（筆者就不放圖了，否則就一張圖用了3遍），筆者這種作法是比較極端的（或者能夠說筆者把現象放大了），此時再把吞吐量當作TPS就出事了。。。。請求全失敗了，TPS應該是0吧？？？？？

給你們舉個栗子，你們都看過趙本山大叔的《鐘點工》小品，裏面有個經典的問題：把大象關進冰箱須要幾步？相信你們都知道答案。咱們換種思惟：假如咱們把這個操做當作一個事務，若是找不到大象，或者沒有冰箱，這個事務都是沒法完成的，也就是說這個事務最終會失敗(事務只有兩種狀態要麼成功要麼失敗)。

那麼何時吞吐量能夠成TPS,從嚴格意義來說就是交易成功率爲100%；還有一種狀況是：交易失敗率在你能夠接受的範圍內（對當前測試總體結果影響不大，到了能夠忽略的程度）。

咱們再來驗證下網上說的方法吧：把請求放在事務控制器裏

腳本結構圖：

有的同窗能夠能會問：事務控制器爲啥不放多個請求，其實從本質上看是沒這個必要的，放多個請求也不影響最終結果。

筆者仍是用以前的操做把100_2.jtl中的請求所有改爲false,再來看下聚合報告結果：

聚合報告結果圖（爲何會整體樣本會是200，筆者以爲問題出在逆向解析過程當中會把JTL結果文件中全部的樣本解析出來）：

吞吐量的值仍是沒有變，此時吞吐量值預期結果應該是零，進而證實網上的所謂的套路不靠譜（感受網上說的增長事務控制器的，目的更偏向與如何把多個請求組裝成一個事務，這也是事務控制的做用）。

4.JMeter聚合報告源碼優化

針對以上問題，筆者查看了聚合報告底層源碼，總結下：聚合報告是無狀態的（狀態是樣本的狀態），只負責統計數據（就是個計數器），統計時只認Sampler的Label，筆者我的感受源生的聚合報告，不是十分合適OLTP。

筆者優化了：統計計算公式，支持GUI頁面控制（默認勾選統計tps，若是不勾選則仍是統計吞吐量）

再看下100.jtl結果文件所有false效果：

筆者手動改下100.jtl改爲只失敗1筆，執行結果以下：