使用場景
對指定介面進行效能測試時，一些常見引數解釋說明。
一鍵併發
可以透過下載最新版的 Apipost 客戶端實現單介面的高效能一鍵併發壓測，如下圖所示
注意：請勿設定太大的併發量或者迴圈次數，這有可能導致直接將被壓服務壓崩潰或者將路由器壓崩潰。參考參考下方 【實踐】部分建議。
底層原理
為實現高效能的併發需求，使用自研的壓測引擎，可以實現一萬以上併發。
專案已經開源，github地址：https://github.com/Apipost-Team/runnerGo
壓測結果計算方式
| 壓測值 | 含義 | 計算方法 |
|---|---|---|
| 總請求數 | 總共傳送送請求總數 | 併發數*輪次 |
| 執行時間 | 壓測任務執行時間 | 任務結束時間-任務開始時間 |
| 成功請求數 | http請求code為200的請求數量 | 略 |
| 失敗請求數 | http請求code非200或者連線異常請求數量 | 略 |
| 錯誤率 | 壓測出錯比例 | 失敗次數/總請求數 * 1000 |
| 總接收資料 | 總結接收到資料總位元組數 | 累加每次返回結果的位元組數量 |
| 每秒請求數 | 每秒平均請求數量 | 請求總次數/請求總時間 |
| 每秒成功請求數 | 每秒平均成功請求數量 | 成功請求總次數/成功請求總時間 |
| 每秒接收位元組數 | 每秒接收平均位元組數 | 總接收位元組數/總請求時間 |
| 最大響應時間 | 最大請求執行時間 | 所有請求中執行最長的時間 |
| 最小響應時間 | 最小請求執行時間 | 所有請求中執行最小的時間 |
| 平均響應時間 | 平均響應時間 | 請求總時間/請求總次數 |
| 10% | 前10%請求完成時間 | 所有請求花費時間正序排序，取10%位置的執行時間 |
| 25% | 前25%請求完成時間 | 所有請求花費時間正序排序，取20%位置的執行時間 |
| 50% | 前50%請求完成時間 | 所有請求花費時間正序排序，取50%位置的執行時間 |
| 75% | 前75%請求完成時間 | 所有請求花費時間正序排序，取75%位置的執行時間 |
| 90% | 前90%請求完成時間 | 所有請求花費時間正序排序，取90%位置的執行時間 |
| 95% | 前95%請求完成時間 | 所有請求花費時間正序排序，取95%位置的執行時間 |
實踐
併發結果很容易外界因素影響，壓測時需要儘量減少外界因素影響。
因此選擇合適併發數對測試介面效能非常重要，並非併發數越大越好。
影響壓測結果外界因素有本機控制程式碼數限制，dns解析速度，網路質量，服務端連線數限制等等。
例如使用1w併發， 很容易出現超過本機最大控制程式碼數限制（一般最大限制1024）， 超過控制程式碼數限制的請求會因為控制程式碼數受限導致連線失敗。
併發數建議先在10， 100， 500， 1000左右分別測試下，如果失敗率小於1%，再考慮逐步增加併發數量。只有增加併發每秒請求數量能持續增加才是健康使用方式