QPS 与并发数是什么关系
两者通过平均响应时间互相换算：QPS 约等于并发数除以平均响应时间（秒）。这说明它们不是独立指标——提高并发并不保证提高吞吐，一旦瓶颈资源饱和，延迟会快速上升，吞吐停滞甚至下降，多出来的并发只变成了排队。
怎么用来做容量判断
先算目标吞吐需要的并发数，再反查线程池与连接池能否满足；如果并发需求超过池容量，请求只能在队列中等待，等待又拉长响应时间，进一步推高所需并发，形成恶性循环。因此容量核算要同时观察吞吐与延迟两条曲线，以拐点而不是极限值作为日常水位。
基本信息
| QPS 口径 | 统计正确完成的请求数每秒 |
|---|---|
| 并发口径 | 在途请求数，包含排队与处理中的请求 |
| 换算关系 | QPS 约等于并发除以平均延迟（秒） |
| 验证方法 | 逐步加压，绘制吞吐与延迟曲线找拐点 |
测算步骤
- 固定负载阶梯加压，每级持续数分钟并逐级提升并发
- 记录每级的实测吞吐、P95、P99 与错误率曲线
- 定位拐点：吞吐不再上升而延迟快速抬升的负载点
- 交叉验证：把实测拐点与公式估算值互相对照
- 以拐点的七成到八成作为日常容量水位，峰值另配冗余
和限流、线程池怎么配合
限流阈值应当来自实测拐点而不是拍脑袋：先找到吞吐不再上升的负载点，再取其一定比例作为限额，才能既保护系统又不过早拒绝合法流量。线程池与连接池的容量要一起核对，因为并发需求会同时落在两者上，其中任意一个饱和都会让请求排队。三者配合的目标是让过载表现为快速失败，而不是表现为延迟无上限增长。
平均延迟会掩盖长尾：容量核算用高分位更稳妥，否则会出现均值指标达标、超时率已经超标的情况，用户体验与监控结论完全相反。