如果你想從頭學習Jmeter,可以看看這個系列的文章哦
https://www.cnblogs.com/poloyy/category/1746599.html
前言
可以搭配上一篇部落格來看哦,是一個整體內容:https://www.cnblogs.com/poloyy/p/13278920.html
Charts 介紹
- 包含了各種詳細資訊圖表,比 GUI 模式的圖表好看且易懂多了!
- 做效能測試,如何發現是否有效能瓶頸?必須從結果圖表中找到鴨!
- 而 html 報告將效能測試可能需要用到的圖表都加進去了,可謂是6666
一共有三大模組
- Over Time
- Throughput
- Response Times
Over Time
一共有 6 個圖表
- Response times Over Time
- Response times Percentiles Over Time
- Active Threads Over Time
- Bytes throughput Over Time
- Latencies Over Time
- Connect Time Over Time
=======>>>> 點選右側即可跳轉對應圖表哦
Response times Over Time
- 指令碼執行期間,不同事務(請求)的響應時間變化趨勢圖
- 包括事務控制器樣本結果
- 重點:可以根據響應時間和變化和TPS以及模擬的併發數變化,判斷效能拐點的範圍
- 一條線代表一個事務(請求)
Response times Percentiles Over Time
- 指令碼執行期間,成功的請求的響應時間百分比分佈圖
- 可理解為聚合報告對應的指標(圖二)
Active Threads Over Time
- 指令碼執行期間,每個執行緒組的活躍執行緒數變化趨勢圖
- 一個執行緒組對應一條線
Bytes throughput Over Time
- 指令碼執行期間,吞吐率變化趨勢圖
- 在容量規劃、可用性測試和大檔案上傳下載場景中,吞吐量是很重要的一個監控和分析指標
- 會忽略事務控制器樣本結果
Latencies Over Time
- 指令碼執行期間,傳送一個完整的請求所需時間的變化趨勢圖
- 可理解理解成:從傳送請求到收到第一個響應所花費的時間
- 包括事務控制器樣本結果
Connect Time Over Time
- 指令碼執行期間,事務(請求)建立連線所花費的平均時間變化趨勢圖
- 包括 SSL 三次握手的時間
- 當出現鏈 Connection Time Out 的錯誤時,Connect Time 就會等於連結超時時間
對應 Jmeter 監視器的元件
Throughput
- Codes Per Second
- Transactions Per Second
- Total Transactions Per Second
- Response Time Vs Request
- Latency Vs Request
=======>>>> 點選右側即可跳轉對應圖表哦
Codes Per Second
指令碼執行期間,響應狀態碼的數量變化趨勢圖
Transactions Per Second(最重要)
- 每秒事務數,即 TPS
- 衡量系統處理能力的重要指標
- 包括事務控制器樣本結果
Response Time Vs Request
平均響應時間與每秒請求數的關係圖
Latency Vs Request
完成一個完整的請求所需平均時間與每秒請求數的關係圖
對應 Jmeter 監視器的元件
Response Times
- Response Time Percentiles
- Response Time Overview
- Time Vs Threads
- Response Time Distribution
=======>>>> 點選右側即可跳轉對應圖表哦
Response Time Percentiles
- 響應時間百分比分佈圖
- 響應時間在某個百分比範圍內的請求在所有請求數中所佔的比率,相比於平均響應時間,這個值更適合用來衡量系統的穩定性。
Response Time Overview
- 響應時間分佈圖
- 展示落在各個平均響應時間區間的請求數情況
Time Vs Threads
- 平均響應時間和執行緒數的對應變化曲線
- 可以通過這個對應的變化曲線來作為確定效能拐點的一個參考值
- 可以選中或取消選中下面的 Sampler
Response Time Distribution
- 響應時間分佈圖
- 不同響應時間區間內,成功響應數是多少