jmeter性能測試重要指標以及性能結果分析

 

1、Aggregate Report 是 JMeter 經常使用的一個 Listener，中文被翻譯爲「聚合報告

若是你們都是作Web應用的性能測試，例如只有一個登陸的請求，那麼在Aggregate Report中，會顯示一行數據，共有10個字段，含義分別以下。

一、Lable：每一個Jmeter的element（例如Http Request）都有一個Name屬性，這裏顯示就是Name屬性的值

二、Samples：表示此次測試一共發出了多少次請求，若是模擬10用戶，每一個用戶迭代10次，那麼這裏顯示100

三、Average：平均響應時間--默認狀況下是單個Request的平均時間，當使用了Transaction Controller時，也能夠以Transaction爲單位顯示平均響應時間

四、Median：50%用戶響應時間

五、90%Line：90%用戶的響應時間

六、Min：最小響應時間

七、Max：最大響應時間

八、Error%：本次測試出現錯誤的請求的數量/請求總數

九、Troughput：吞吐量---默認狀況下表示每秒完成的請求數量（Request per second）,當使用了Transaction Controller時，也能夠表示相似Loadruner的Transaction per second數

十、KB/Sec：每秒從服務器端接收的數量，至關於Loadrunner的Throughput/Sec

2、描述性統計與性能結果分析

疑惑點：90％響應時間是什麼意思？這個值在進行性能分析時有什麼做用？

爲何要有90％用戶響應時間？由於在評估一次測試的結果時，僅僅有平均事務響應時間是不夠的。爲何這麼說？你能夠試着想一想，是否平均事務響應時間知足了性能需求就表示系統的性能已經知足了絕大多數用戶的要求？

假若有兩組測試結果，響應時間分別是 {1，3，5，10，16} 和 {5，6，7，8，9}，它們的平均值都是7，你認爲哪次測試的結果更理想？

假若有一次測試，總共有100個請求被響應，其中最小響應時間爲0.02秒，最大響應時間爲110秒，平均事務響應時間爲4.7秒，你會不會想到最小和最大響應時間如此大的誤差是否會致使平均值自己並不可信？

爲了解答上面的疑問，咱們先來看一張表：

 

在上面這個表中包含了幾個不一樣的列，其含義以下：

CmdID   測試時被請求的頁面

NUM      響應成功的請求數量

MEAN    全部成功的請求的響應時間的平均值

STD DEV      標準差（這個值的做用將在下一篇文章中重點介紹）

MIN              響應時間的最小值

50 th(60/70/80/90/95 th)          若是把響應時間從小到大順序排序，那麼50％的請求的響應時間在這個範圍以內。後面的60/70/80/90/95 th 也是一樣的含義

MAX      響應時間的最大值

我想看完了上面的這個表和各列的解釋，不用多說你們也能夠明白個人意思了。我把結論性的東西整理一下：

一、90％用戶響應時間在 LoadRunner中是能夠設置的，你能夠改成80％或95％；

二、對於這個表，LoadRunner中是沒有直接提供的，你能夠把LR中的原始數據導出到Excel中，並使用Excel中的PERCENTILE 函數很簡單的算出不一樣百分比用戶請求的響應時間分佈狀況；

三、(重點)從上面的表中來看，對於Home Page來講，平均事務響應時間(MEAN)只同70％用戶響應時間相一致。也就是說假如咱們肯定Home Page的響應時間應該在5秒內，那麼從平均事務響應時間來看是知足的，可是實際上有10-20％的用戶請求的響應時間是大於這個值的；對於Page 1也是同樣，假如咱們肯定對於Page 1 的請求應該在3秒內獲得響應，雖然平均事務響應時間是知足要求的，可是實際上有20-30％的用戶請求的響應時間是超過了咱們的要求的；

四、你能夠在95 th以後繼續添加96/ 97/ 98/ 99/ 99.9/ 99.99 th，並利用Excel的圖表功能畫一條曲線，來更加清晰表現出系統響應時間的分佈狀況。這時候你也許會發現，那個最大值的出現概率只不過是千分之一甚至萬分之一，並且99％的用戶請求的響應時間都是在性能需求所定義的範圍以內的；

五、 若是你想使用這種方法來評估系統的性能，一個推薦的作法是儘量讓你的測試場景運行的時間長一些，由於當你得到的測試數據越多，這個響應時間的分佈曲線就越接近真實狀況；

六、在肯定性能需求時，你能夠用平均事務響應時間來衡量系統的性能，也能夠用90％或95％用戶響應時間來做爲度量標準，它們並不衝突。實際上，在定義某些系統的性能需求時，必定範圍內的請求失敗也是能夠被接受的；

七、上面提到的這些內容實際上是與工具無關的，只要你能夠獲得原始的響應時間記錄，不管是使用LoadRunner仍是JMeter或者OpenSTA，你均可以用這些方法和思路來評估你的系統的性能。

聚合報告中的，吞吐量=完成的transaction數/完成這些transaction數所須要的時間；平均響應時間=全部響應時間的總和/完成的transaction數；失敗率=失敗的個數/transaction數總的來講，對於jmeter的結果分析，主要就是對jtl文件中原始數據的整理

八、TestPlan ：是整個Jmeter測試執行的容器

九、ThreadGroup ：模擬請求，定義線程數、Ramp-Up Period、循環次數。

十、Step1 ：循環控制器 ，控制Sample的執行次數。

十一、怎樣計算Ramp-up period時間？
Ramp-up period是指每一個請求發生的總時間間隔，單位是秒。若是Number of Threads設置爲5，而Ramp-up period是10，那麼每一個請求之間的間隔就是10／5，也就是2秒。Ramp-up period設置爲0，就是同時併發請求。

12.、爲何Aggregate Report結果中的Total值不是真正的總和？
JMeter給結果中total的定義是並不徹底指總和，爲了方便使用，它的值表現了所在列的表明值，好比min值，它的total就是所在列的最小值。

1三、在運行結果中爲什麼有rate爲N/A的狀況出現？
可能由於JMeter自身問題形成，再次運行能夠獲得正確結果。

1四、在使用JMeter測試時，是徹底模擬用戶操做麼？形成的結果也和用戶操做徹底相同麼？
是的。JMeter徹底模擬用戶操做，因此操做記錄會所有寫入DB.在運行失敗時，可能會產生錯誤數據，這就取決於腳本檢查是否嚴謹，不然錯誤數據也會進入DB，給程序運行帶來不少麻煩。

 

一、當心緩存（相似查詢接口壓測，先問問有沒有作緩存）二、瓶頸處持續壓測，測試系統穩定性三、線上真實的如出一轍的環境配置四、緩存洞穿，持續壓測/去緩存壓測/有緩存壓測