當系統開發完成後，客戶或主管常會詢問 API 的承載能力？
如果隨意回覆「應該能承擔 100 個同時存取」這樣的答案，顯得不夠專業
作為工程師，我們應該提供具體的科學數據
因此，通常會先撰寫壓測腳本，使用壓力測試工具來模擬真實環境，並將測試結果整理成可供決策的報告數據
這裡使用 JMeter 進行壓測，但報告中的一些參數並不直觀
因此我整理了一些關鍵數據的解釋，作為參考
也方便日後使用時檢視這些數據的意義，幫助更好地分析系統的表現
測試環境
- API URL: http://xxxx/API/GetProduct
- 執行時間: 2021-06-25 18:00:00
- 操作系統: Windows Server 2019 Standard
- CPU: Intel Xeon E5-2670 @ 2.60GHz (8 cores)
- 內存: 16 GB
- 磁碟: 500 GB SSD
- 網絡: 中華電信 100M/40M 固定IP
測試資料
- 用戶: 1人
- 商品數量: 1000個
測試腳本
- 執行緒: 1個
- 啟動延遲: 0秒
- 迴圈持續時間: 10分鐘
- 迴圈延遲: 1秒
測試腳本流程
- 1個用戶輪流呼叫1000種商品, 呼叫API取得商品資訊
- 延遲1秒, Loop…
預期結果
- 吞吐量目標：期望 API 能在每秒至少處理 10 個請求
- 響應時間目標：每次請求的平均響應時間應控制在 2000 毫秒以下
- 錯誤率：希望錯誤率保持在 0%
彙整報告
- 總請求次數(#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: 指每個請求發生的總時間間隔，單位是秒
結果分析
- 平均響應時間：測試結果顯示平均響應時間為 2744 毫秒，超過預期目標的 2000 毫秒，顯示系統在高並發下存在性能瓶頸，可能需要優化伺服器端的處理邏輯
- 吞吐量：每秒 10.1 個請求達到預期，顯示系統能承擔較高的負載
- 最大響應時間：最大響應時間達到 39776 毫秒，需深入分析高延遲原因，可能是伺服器資源被耗盡或外部 API 影響