接口压测目标怎么定：从日访问量推导 QPS 目标的实用方法
导读：本文给出接口压测目标的可执行推导方法：有线上 QPS 的接口按"正常流量 10 倍且响应时间 200ms 内"设定目标，没有监控的接口用 80/20 法则从日访问量反推基准 TPS（TPS = 日访问量×80% /（活跃时长×3600×20%），如日访问 100 万约 46 TPS），再按 3 倍、10 倍分档加压直到报错以探明容量上限。适合需要为接口设定压测档位并同步盯机器、数据库、中间件指标的性能测试工程师。
分类：性能测试 ｜ 标签：性能测试、压测、QPS
做接口压测时，最常被问到的两个问题就是：压到多少 QPS 才算达标？目标 TPS 怎么定？ 本文整理一套从"目标设定"到"指标观察"的实用方法，拿日访问量就能推出一组可执行的压测档位。
一、压测目标设定原则
压测目标先于压测执行定清楚，实践中通常按以下原则设定：
- 有线上 QPS 参考的接口：压到线上正常 QPS 的 10 倍，且目标响应时间仍在 200ms 以内——验证系统在 10 倍流量冲击下依然快速、稳定。
- 拿不到线上 QPS 的接口：兜底目标至少压到 50 QPS，响应时间仍要求 200ms 以内。
- 已达标接口继续加压：满足"10 倍 QPS 且响应 200ms 内"的接口，继续加压直到接口报错，找出系统的真实容量上限和出错下限。
- 压测全程关注 CPU、内存等资源使用情况，判断瓶颈是否出在资源侧。
二、从日访问量估算 TPS
线上接口常常没有现成的 QPS 监控，此时可以从「日访问量」反推目标 TPS。核心假设是经典的 80/20 法则：80% 的访问量集中在 20% 的时间内完成。
据此得到估算公式：
TPS = 日访问量 × 80% /（活跃时长(小时) × 3600 × 20%）其中「活跃时长」按接口的实际功能调整：全天型业务取 24 小时，突发型业务取高峰 8 小时。
计算示例
- 日访问量 100 万，按全天 24 小时活跃计算： TPS = 1,000,000 × 80% /（24 × 3600 × 20%）≈ 46 TPS
- 日访问量 5 万，高峰时长为 8 小时： TPS = 50,000 × 80% /（8 × 3600 × 20%）≈ 7 TPS
压测时以估算的 TPS 为基准，分别观察 3 倍、10 倍访问量下系统的承载能力，以及系统开始出错的下限。注意 JMeter 的 HTML 报告中的「吞吐量」约等于 TPS，可用来双向反查压测强度是否达标。
由基准 TPS 可推出一组压测档位（对应上面 7 TPS 的例子）：
| 压测档位 | 目标 TPS | 说明 |
|---|---|---|
| 基准 | 7 | 1 倍基准流量 |
| 负载 1 | 21 | 3 倍基准流量 |
| 负载 2 | 70 | 10 倍基准流量 |
| 负载 3 | 持续加压至报错 | 探明容量上限 |
三、压测类型分级
| 压测类型 | 压测时间区间 | 场景策略 | 服务端是否报错 |
|---|---|---|---|
| 基准测试 | 记录压测起止时间 | 1 个虚拟用户（1VU），持续 1 分钟 | 否 |
| 负载测试 | 记录压测起止时间 | 10 个虚拟用户（10VU），持续 1 分钟 | 是（观察报错位置） |
基准测试用于建立单用户下的性能基线；负载测试逐步加压，观察服务端报错的出现位置，定位容量拐点。
四、压测需要关注的监控指标
压测不只是看响应时间，还要把机器、数据库、中间件的状态一起盯住：
| 监控对象 | 关注指标 |
|---|---|
| JMeter 压测数据 | 成功率、平均响应时间、90% 请求响应时间、QPS/吞吐量 |
| 机器监控 | CPU（%）、内存（MB）、磁盘 IO（读/写速率）、网卡流量（入/出） |
| DB 监控 | CPU（%）、内存（%） |
| 中间件 | 消息队列、Redis 的延迟与积压情况 |
小结
压测目标不必拍脑袋：有线上 QPS 就按"10 倍 + 200ms"来压；没有就用 80/20 法则从日访问量推基准 TPS，再按 3 倍、10 倍分档加压，压到报错为止。过程中同步盯好机器、数据库、中间件指标，一次把"系统能扛多少"和"瓶颈在哪里"都问清楚。