使用場景
對指定接口進行性能測試時，一些常見參數解釋說明。
一鍵併發
可以通過下載最新版的 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%，再考慮逐步增加併發數量。只有增加併發每秒請求數量能持續增加纔是健康使用方式