Jmeter4.0---- 測試數聽說明（17）

1.說明

jmeter工具對於請求的測試結果，有多種形式展示，可是數據比較難懂，如今針對不一樣的展示作具體的說明。

 

2.監聽器

（一）圖形結果

 

(1)樣本數目：總共發到服務器的請求數

(2)最新樣本：服務器響應最後一個請求的處理時間（單位：毫秒）

(3)平均：全部取樣器結果的響應時間平均值（總運行時間除以發送到服務器的請求數）

(4)偏離：服務器響應時間變化，離散程度測量值的大小，即數據的分佈。

(5)吞吐量：服務器每分鐘處理的請求數

(6)中值：全部取樣器結果的響應時間中間值（有一半的服務器響應時間低於該值而另外一半高於該值）

(7)X軸：取樣器個數的均勻分部軸

(8)y軸：處理時間（單位：毫秒）

 

（二）聚合報告

 聚合報告中的時間單位ms（1000ms=1s）

(1)Label : 每一個JMeter 的element(例如HTTP Request)都有一個Name屬性，這裏顯示的就是Name屬性的值

(2)#Samples : 表示你此次測試中一共發出了多少請求，若是測試計劃模擬10個用戶，每一個用戶迭代10次，這裏就會顯示100

(3)Average : 平均響應時間，默認狀況下是單個Request的平均響應時間，當使用了事務控制器時，也能夠以事務爲單位顯示平均響應時間

(4)Median : 中位數，也就是50%用戶的響應時間（據按由小到大的順序排列後，取出第50%位）

(5)90%Line : 90%用戶的響應時間（據按由小到大的順序排列後，取出第90%位）

(6)95%Line : 95%用戶的響應時間（據按由小到大的順序排列後，取出第95%位）

(7)99%Line : 99%用戶的響應時間（據按由小到大的順序排列後，取出第99%位）

(8)Min : 最小響應時間

(9)Max : 最大響應時間

(10)Error% : 錯誤率，本次測試中出現錯誤的請求的數量/請求總數

(11)Throughput : 吞吐量，默認狀況下表示每秒完成的請求數(Request per Second)

(12)KB/Sec : 每秒從服務器端接受到的數據量（單位：千字節/秒）

(13)Received KB/sec----每秒從服務器端接收到的數據量（單位：千字節/秒）

(14)Sent KB/sec----每秒從客戶端發送的請求的數量（單位：千字節/秒）

 

（三）用表格查看結果

(1)Sample:每一個請求的序號

(2)start time:每一個請求開始時間

(3)thread name:每一個線程組名稱

(4)label：請求類型，對應在測試計劃下填寫的請求名稱

(5)Sample time：每一個請求所花時間，單位毫秒（0.001秒(s)=1毫秒(ms)    1秒(s)=1000毫秒(ms)  ）

(6)Status：請求狀態，若是爲 √ 則表示成功，若是爲 × ，則表示失敗。

(7)Bytes：響應的字節數，請求的字節數。

(8)Sent Bytes：發送的字節數。 

(9)Latency：延遲的時間，等待時長。（單位：毫秒）

(10)Connect Time(ms)：鏈接服務器的時間。（單位：毫秒）

(11)樣本數目：全部請求個數，樣本數目 = 線程數（請求用戶數）* 請求次數 。（單位：個）

(12)最新樣本：最新樣本響應時間，表示服務器響應最後一個請求的時間。（單位：毫秒）

(13)平均：全部請求的平均響應時間。（單位：毫秒）

(14)偏離：服務器響應時間變化、離散程度測量值的大小，或者，換句話說，就是數據的分佈。（偏離值是一個觀察測試環境和系統穩定性的數據）

 

3.名詞解釋及分析

偏離值：偏離值是一個觀察測試環境和系統穩定性的數據。偏離值越小則環境越穩定，所測得的數據越有效，反之，若是偏離值太大則說明環境不穩定，在這種狀況下測得的數據就沒什麼價值，因此在測試的時候，必需要保證偏離值是小的。（可參考：http://blog.sina.com.cn/s/blog_5034424d010080ay.html）

 

吞吐率：單位時間內服務器處理的請求數來描述其併發處理能力。吞吐率，是單位時間內網絡上傳輸的數據量，特指web服務器單位時間內處理的請求數。吞吐率是衡量網絡性能的重要指標。一般狀況下，吞吐率用「字節數/秒」來衡量。也能夠用「請求數/秒」來衡量。吞吐量除以時間，所獲得的單位時間內的數據量就是吞吐率。吞吐率表明着單位時間內所能承受的壓力，是測試中一個重要的指標。經過比較吞吐量，能夠發現系統的運行狀態。當隨着併發數增長時，吞吐率是不斷增長的，當達到一個服務器極限後，再增長併發數，吞吐率會急速降低，直至服務器崩潰。因此，當達到臨界點（吞吐量最高點，負載和處理均衡時）爲「最大吞吐率」，是系統在運行下的一個理想閾值範圍。

備註：一個請求仍是一個頁面，它的本質都是在網絡上傳輸的數據，那麼用來表述數據的單位就是字節數。

 

吞吐量：是指在一次性能測試過程當中，網絡上傳輸的數據量的總和。對於交互式應用來講：吞吐量指標反映的是服務器承受的壓力。在容量規劃的測試中：吞吐量是一個重點關注的指標，由於它可以說明系統級別的負載能力。另外，在性能調優過程當中，吞吐量指標也有重要的價值。

 

好比：一個大型工廠，他們的生產效率與生產速度很快，一天生產10W噸的貨物，結果工廠的運輸能力不行，就兩輛小型三輪車一天拉2噸的貨物，說明的是這個運輸能力（吞吐量）是整個系統的瓶頸。

只用吞吐量來衡量一個系統的性能（輸出能力）是極其不許確的。
用個最簡單的例子說明，一個水龍頭開一天一晚上，流出10噸水；10個水龍頭開1秒鐘，流出0.1噸水。此時固然是一個水龍頭的吞吐量大。可是，你能說1個水龍頭的出水能力是10個水龍頭的強嗎？顯然不能。
因此，咱們要加單位時間，看誰1秒鐘的出水量大，這就是吞吐率

TPS：事務(Transaction Per second),就是用戶某一步或幾步操做的集合。每秒鐘用戶向web服務器提交的HTTP請求數。同時，要保證它有一個完整意義。每秒鐘系統可以處理事務或交易的數量，它是衡量系統處理能力的重要指標。這個指標是web 應用特有的一個指標；web應用是「請求-響應」模式，用戶發一個申請，服務器就要處理一次，因此點擊是web應用可以處理的交易的最小單位。若是把每次點擊定義爲一個交易，點擊率和TPS就是一個概念。點擊率越大，對服務器的壓力也越大，點擊率只是一個性能參考指標，重要的是分析點擊時產生的影響。

點擊率：能夠看作是TPS的一種特定狀況。更能體現用戶端對服務器的壓力。
TPS：更能體現服務器對客戶請求的處理能力。

好比：用戶對某一個頁面的一次請求，用戶對某系統的一次登陸，淘寶用戶對商品的一次確認支付過程。這些咱們均可以看做一個事務。


吞吐量，吞吐率的意義：

• 吞吐量的限制是性能瓶頸的一種重要表現形式，所以，有針對地對吞吐量設計測試，能夠協助儘快定位到性能冰晶所在的位置。
• 80%系統的性能瓶頸都是由吞吐量制約。
• 併發用戶和吞吐量瓶頸之間存在必定的關聯。
• 經過不斷增長併發用戶數和吞吐量觀察系統的性能瓶頸。而後，從網絡、數據庫、應用服務器和代碼自己4個環節肯定系統的性能瓶頸。

 

聚合報告中部分值的計算方法：

• 吞吐量 = 完成的請求數 / 完成這些請求數所須要的時間
• 平均響應時間 = 全部響應時間的總和 / 完成的請求數
• 失敗率 = 失敗的個數 / 總數
• 時間的計算方法是：經過timeStamp時間戳（發出的起始時間）相減而得