系統開發完，有時候客戶或主管會問你這個API能承受的壓力為何?
比較不科學的回答就會說”應該可以承擔同時100個存取”
但身為一位工程師要用科學數據的角度給答案
通常就會把需求寫成壓測腳本
讓壓力測試工具跑，產出的報告數據整理成客戶或主管可做決策的數據
這邊是使用JMeter工具，產出來的數據有些數值有看沒有懂
因此簡單紀錄一下分析報告的參數說明，給下次的我參考或給有需要的人參考
測試環境
- 線路: 中華電信
- API URL: http://xxxx/API/GetProduct
- 執行時間: 2021-06-25 18:00:00
- 平台: 測試站
測試資料
- 用戶: 1人
- 商品數量: 1000個
測試腳本
- 執行緒: 1個
- 啟動延遲: 0秒
- 迴圈持續時間: 10分鐘
- 迴圈延遲: 1秒
測試腳本流程
- 1個用戶輪流呼叫1000種商品, 呼叫API取得商品資訊
- 延遲1秒, Loop…
彙整報告
- 總請求次數(#Samples): 6127次
- 平均響應時間(Average): 2744(ms)
- 最小響應時間(Min): 177(ms)
- 最大響應時間(Max): 39776(ms)
- 標準偏移量(Std.Dev): 4400.29
- 錯誤率(Error %): 0.00%
- 每秒請求吞吐量(Throughtput): 10.1/sec
- 每秒收到流量(Received KB/sec): 3.90
- 每秒發送流量(Send KB/sec): 2.46
- 平均資料流量(Avg.Bytes): 394.5
- #Samples: 本次測試共發出了多少次請求
- Average: Request 的平均響應時間
- Median: 中位數 (50％ 用戶的響應時間)
- 90% Line: 90％ 用戶的響應時間
- Min: 最小響應時間
- Max: 最大響應時間
- Error%: 本次測試中出現錯誤的請求的數量/請求的總數
- Throughput: 吞吐量，默認情況下表示每秒完成的請求數(Request per Second)，伺服器能夠接受的最大速率
- KB/Sec: 每秒從伺服器接收到的數據量
- ThreadGroup 線程組: 代表一定數量的並發用戶，它可以用來模擬並發用戶發送請求
- Ramp-up period: 指每個請求發生的總時間間隔，單位是秒