【jmeter】jmeter監聽器：圖形結果、聚合報告、用表格察看結果指標報告分析
阿新 • • 發佈：2018-12-12
目錄
一、圖形結果
- 橫座標：時間。（單位：毫秒）
- 縱座標：處理時間。（單位：毫秒）
- 樣本數目：樣本數目 = 執行緒數（請求使用者數）* 請求次數 。（單位：個）
- 最新樣本：最後一個請求的處理時間。（單位：毫秒）
- 偏離：表示伺服器響應時間變化、離散程度測量值的大小，或者，換句話說，就是資料的分佈。（單位：個）
- 吞吐量：伺服器每分鐘處理的請求量 。（單位：請求數/分鐘）
- 平均：每個請求的平均處理時間 。（單位：毫秒）
- 中值：所有處理時間的中位數，有一半的伺服器響應時間低於該值而另一半高於該值。（單位：毫秒）
二、聚合報告
- Label：每個請求的自定義名稱（無修改時預設顯示請求型別，如Http，FTP等請求）；“TOTAL”是所有請求的總統計。
- #Samples：採集器的數量，總共傳送到伺服器的樣本數目。樣本數目 = 執行緒數 * 迴圈次數。（單位：個）
- Average：單個請求的平均響應時間，預設是單個Request的平均響應時間。（單位：毫秒）
當使用了Transaction Controller時，也可以以Transaction為單位顯示平均響應時間。
- Median：響應時間中位數，N個數據從小到大排列，第N/2個數的數值。（單位：毫秒）
- 9x%Line：所有響應時間資料中，9x%的響應時間都小於此值。（單位：毫秒）
所有響應時間，N個數據按從小到大排列，取第（9x% * N）個數的響應時間數值。
①9X%Line的含義：
資料按由小到大的順序排列後，取出第9X%位。 比如：2、5、1、5、3、8、0、2、1、9中，90%line就是8： 1. 資料按照升序進行排列 0、1、1、2、2、3、5、5、8、9 2. 10個數字，第90%位就是10*90%，第9位 3. 第9位是8，所以90%line就是8
②9X%Line的意義：
⒈當一組數升序排列好後，選出第9X%位，那就意味著前9X%個數字都小於等於它，也就代表著改組資料中有9X%的數小於等於該數字。
因此：
90%line就代表該組資料中有90%的數字小於等於該值。
95%line就代表該組資料中有95%的數字小於等於該值。
99%line就代表該組資料中有99%的數字小於等於該值。
⒉用在效能測試上，將顯得十分的有意義。
比如：在響應時間中，代表著一組請求中，9X%請求響應不會超過該值。可以有效的進行效能評估。
- Min：最短的響應時間。（單位：毫秒）
- Max：最長的響應時間。（單位：毫秒）
- Error%：出錯的百分率，錯誤率 = 本次測試中出現錯誤的請求的數量 / 請求的總數 * 100% 。
- Throughput：吞吐率，表示每秒完成的請求數，吞吐率 = 請求數 / 總時間（秒）。（單位：個/秒）
當使用了 Transaction Controller 時，也可以表示類似 LoadRunner 的 Transaction per Second 數。
- Received KB/sec：伺服器端接收速率，每秒從伺服器端接收到的資料量，即：收到的千位元組每秒的吞吐量測試。（單位：千位元組/秒）
- Sent KB/sec：客戶端接收速率，每秒從客戶端傳送的請求的數量，即：傳送的千位元組每秒的吞吐量測試。（單位：千位元組/秒）
①吞吐率：
⒈吞吐率（Throughput）：單位時間內伺服器處理的請求數來描述其併發處理能力，單位是 “req/s”。
⒉吞吐率，特指Web伺服器單位時間內處理的請求數。
⒊吞吐率，是單位時間內網路上傳輸的資料量，也可以指單位時間內處理客戶請求數量。
⒋吞吐率是衡量網路效能的重要指標。通常情況下，吞吐率用“位元組數/秒”來衡量。也可以用“請求數/秒”和“頁面數/秒”來衡量。
備註：一個請求還是一個頁面，它的本質都是在網路上傳輸的資料，那麼用來表述資料的單位就是位元組數。
⒌吞吐量除以時間，所得到的單位時間內的資料量就是吞吐率。
⒍吞吐率代表著單位時間內所能承受的壓力，是測試中一個重要的指標。
通過比較吞吐量，可以發現系統的執行狀態。
⒎當隨著併發數增加時，吞吐率是不斷增加的，當達到一個伺服器極限後，再增加併發數，吞吐率會急速下降，直至伺服器崩潰。
所以，當達到臨界點（吞吐量最高點，負載和處理均衡時）為“最大吞吐率”，是系統在執行下的一個理想閾值範圍。
②吞吐量：
⒈吞吐量：是指在一次效能測試過程中，網路上傳輸的資料量的總和。
⒉對於互動式應用來說：吞吐量指標反映的是伺服器承受的壓力。
在容量規劃的測試中：吞吐量是一個重點關注的指標，因為它能夠說明系統級別的負載能力。
另外，在效能調優過程中，吞吐量指標也有重要的價值。
比如：一個大型工廠，他們的生產效率與生產速度很快，一天生產10W噸的貨物，結果工廠的運輸能力不行，就兩輛小型三輪車一天拉2噸的貨物，說明的是這個運輸能力（吞吐量）是整個系統的瓶頸。
⒊只用吞吐量來衡量一個系統的效能（輸出能力）是極其不準確的。
用個最簡單的例子說明，一個水龍頭開一天一夜，流出10噸水；10個水龍頭開1秒鐘，流出0.1噸水。
此時當然是一個水龍頭的吞吐量大。但是，你能說1個水龍頭的出水能力是10個水龍頭的強嗎？顯然不能。
所以，我們要加單位時間，看誰1秒鐘的出水量大，這就是吞吐率。③TPS：
⒈TPS:事務(Transaction Per second),就是使用者某一步或幾步操作的集合。同時，要保證它有一個完整意義。
比如：使用者對某一個頁面的一次請求，使用者對某系統的一次登入，淘寶使用者對商品的一次確認支付過程。
這些我們都可以看作一個事務。
⒉TPS:每秒鐘系統能夠處理事務或交易的數量，它是衡量系統處理能力的重要指標。
⒊點選率：可以看做是TPS的一種特定情況。
點選率：更能體現使用者端對伺服器的壓力。
TPS：更能體現伺服器對客戶請求的處理能力。
⒋TPS:每秒鐘使用者向web伺服器提交的HTTP請求數。
這個指標是web 應用特有的一個指標；web應用是“請求-響應”模式，使用者發一個申請，伺服器就要處理一次，所以點選是web應用能夠處理的交易的最小單位。
如果把每次點選定義為一個交易，點選率和TPS就是一個概念。
點選率越大，對伺服器的壓力也越大，點選率只是一個性能參考指標，重要的是分析點選時產生的影響。
注意：這裡的點選不是指滑鼠的一次“單擊”操作，因為一次“單擊”操作中，客戶端可能向伺服器發現多個HTTP請求。④吞吐量、吞吐率的意義：
⒈吞吐量的限制是效能瓶頸的一種重要表現形式，因此，有針對地對吞吐量設計測試，可以協助儘快定位到效能冰晶所在的位置。
⒉80%系統的效能瓶頸都是由吞吐量制約。
⒊併發使用者和吞吐量瓶頸之間存在一定的關聯。
⒋通過不斷增加併發使用者數和吞吐量觀察系統的效能瓶頸。然後，從網路、資料庫、應用伺服器和程式碼本身4個環節確定系統的效能瓶頸。⑤聚合報告中部分值的計算方法：
1. 吞吐量 = 完成的請求數 / 完成這些請求數所需要的時間
2. 平均響應時間 = 所有響應時間的總和 / 完成的請求數
3. 失敗率 = 失敗的個數 / 總數
4. 時間的計算方法是：通過timeStamp時間戳（發出的起始時間）相減而得三、用表格察看結果
- Sample#：每個請求的序號。
- Start Time：每個請求開始時間。（時：分：秒.毫秒）
- Thread Name：每個執行緒的名稱（執行緒序號-第N次迴圈次數）。
- Label：每個請求的自定義名稱（無修改時預設顯示請求型別，如Http，FTP等請求）。
- Sample Time(ms)：每個請求的響應時間。（單位：毫秒）
- Status：請求狀態，如果為勾則表示成功，如果為叉表示失敗。
- Bytes：響應的位元組數，請求的位元組數。
- Sent Bytes：傳送的位元組數。
- Latency：延遲的時間，等待時長。（單位：毫秒）
- Connect Time(ms)：連線伺服器的時間。（單位：毫秒）
- 樣本數目：所有請求個數，樣本數目 = 執行緒數（請求使用者數）* 請求次數 。（單位：個）
- 平均：所有請求的平均響應時間。（單位：毫秒）
- 最新樣本：最新樣本響應時間，表示伺服器響應最後一個請求的時間。（單位：毫秒）
- 偏離：伺服器響應時間變化、離散程度測量值的大小，或者，換句話說，就是資料的分佈。
①Bytes：
Byte，位元組
位元組是由8個位所組成，可代表一個字元(A~Z)、數字(0~9)、或符號(,.?!%&+-*/)，是記憶體儲存資料的基本單位。
1 byte = 8 bit
1 KB = 1024 bytes =210 bytes
1 MB = 1024 KB = 220 bytes
1 GB = 1024 MB = 230 bytes