别再用 QPS 计算并发数了！我曾经也犯了这个错误

✍️ 前言：一次“压测误区”的反思

在一次压测计划中，我想要模拟系统在 QPS 为 500 的情况下运行一分钟，于是直接算了下：

500 QPS × 60 秒 = 30,000 请求

我很自然地把这个数当成“发起请求的总数”，在压测工具里配置成了对应的并发请求和速率。
可实际执行后，结果完全不对劲：服务器很快就吃不消，响应成功数远低于预期，日志也开始大量报错。

后来我才意识到，原来我混淆了 QPS 的含义。
压测工具配置的是发起请求数（RPS），而我想要的是成功处理数（QPS）。
这之间的误解，足以让一次压测结果严重失真。

📌 QPS、RPS、TPS 到底有啥区别？

概念 全称 关注点 说明
QPS Queries Per Second 服务端处理能力 每秒成功响应的请求数
RPS Requests Per Second 客户端施压能力 每秒发起的请求数，不一定全部处理成功
TPS Transactions Per Second 事务处理能力 每秒完成的事务数量（如数据库事务）

🎯 举个例子说明问题

假设某系统在 1 秒内：

  • 接收了 100 个请求（RPS = 100）
  • 实际只处理了其中的 80 个（QPS = 80）

这就说明当前服务已经出现了处理瓶颈。RPS 代表了你希望系统处理的压力，QPS 则代表系统真正扛下的能力。

所以，在系统性能评估中：

  • RPS 越高，意味着你施加的压力量越大
  • QPS 越高，意味着系统的处理能力越强

🛠 在压测工具中如何体现？

以我们常用的 JMeter 和 Locust 为例：

✅ JMeter

  • 设置线程数和循环次数，模拟的是 RPS
  • 报表中统计的“每秒成功响应数”是 QPS

✅ Locust

  • 可以直接设置“每秒发起请求数”，即 RPS
  • 后台 UI 中的统计图表会展示 QPS 的变化趋势

也就是说，在压测工具中我们通常设置的是 RPS，而观察的结果才是 QPS。
如果你错误地用 QPS 作为设置参数，就会导致实际发起请求数远大于系统处理能力，从而产生误判。

❌ 我的错误做法回顾

我曾以为：

QPS 就是我要每秒发出的请求数，所以直接用它去设定并发和速率。

但事实是：

  • 压测工具设置的是 RPS；
  • QPS 是结果，由系统的处理能力决定，不能直接“配置”出来。

所以我的测试其实是在用 RPS = 500 压系统，而不是“系统能稳定处理 500 请求”的验证。

结果当然就是，系统很快打满，响应超时、失败率飙升，QPS 也远达不到预期。

✅ 正确的理解方式是：

  • QPS 是观测值：测试过程中系统每秒实际处理完成的请求数量；
  • RPS 是输入参数：我们对系统施加的压力量；

因此如果你的目标是“系统达到 QPS = 500”，你应该：

  1. 配置合理的 RPS 值；
  2. 逐步加压；
  3. 观察 QPS 是否随之提升；
  4. 评估在什么点系统开始失控或无法线性提升处理能力。

💡 我的实践建议

  • 目标明确：先明确你的压测目标是测客户端发压能力（RPS）还是服务端承压能力（QPS）；
  • 逐步施压：用阶梯式压测或线性提升 RPS 的方式，逐步逼近系统极限；
  • 实时观测：通过 APM 工具、日志、Prometheus 或压测工具自身统计，实时观测 QPS、失败率、响应时间等核心指标；
  • 聚焦瓶颈点：一旦 QPS 不再随 RPS 增加，就要开始分析：是 CPU？数据库？网络？线程池？找出系统的限速器。

🧩 总结一句话

QPS 是系统抗压的“结果”，RPS 是你施加的“压力”——两者混淆只会让压测失真。

🎯 最后的提醒

如果你正在做接口压测，请务必检查以下问题：

  • 你配置的是 RPS 还是 QPS？
  • 你设定的目标，是系统性能的结果，还是工具的输入？
  • 你是否用对了这些指标的含义？

我已经踩过一次坑了，如果你刚好也走到了这一步，希望这篇文章能帮你少走一点弯路。