压测看起来是测试团队的事，但容量评估、瓶颈定位、优化验证都绕不开它——不懂压测指标，连”系统能扛多少量”都回答不了。本文聚焦开发者最常踩坑的四个点：指标之间的关系、工具怎么选、全链路压测难在哪、报告数字怎么读。

QPS、TPS、RT、并发数：用 Little 定律串起来

先把词汇表理清：

  • RT（响应时间）：客户端发出请求到收到完整响应的时间，含网络、网关和服务端处理。
  • QPS：每秒处理的查询/请求数，接口和数据库场景最常用；RPS 强调每秒请求数，接口压测口径更精确。
  • TPS：每秒完成的业务事务数。一次下单算 1 TPS，背后可能是查库存、建订单、扣库存、调支付共 4 个 RPS——TPS 是业务语义，QPS/RPS 是技术语义，换算关系取决于业务链路。
  • 并发数：同一时刻系统正在处理（含排队）的请求数，不是在线用户数。

四者的关系由 Little 定律给出：系统未饱和的稳态下，平均在途请求数 ≈ 吞吐量 × 平均响应时间。例如 QPS 500、平均 RT 200ms，系统内平均同时存在 100 个在途请求。这个公式的工程用途是容量换算：给定目标 QPS 和预期 RT，就能反推线程池、连接池需要多大的并发容量。

要注意公式的边界：它只在线性区间成立。并发继续增加，CPU 调度、锁争用和排队时间会一起放大，RT 非线性上升，吞吐量到达拐点后进入平台期甚至掉头向下——压测报告里这条”曲棍球棒曲线”的拐点，就是系统的真实容量上限。所以纸面估算只能当起点，真实极限必须压出来。

压测工具的定位

工具 特点 适用
JMeter 功能全，GUI 调试脚本、CLI 正式压测 复杂链路、企业级场景
Gatling / k6 代码驱动，报告与 CI 友好 开发自维护脚本、SLO 回归
wrk / ab 轻量高性能 单接口快速摸底
Locust Python 描述用户行为 复杂行为建模

工具本身不产生结论，选哪个取决于谁维护脚本、要不要进 CI。比工具更重要的是压测方法：脚本要贴近真实业务的接口比例和数据分布（读多写少的系统别把写接口打得太狠），要准备合法的鉴权与测试数据；线上压测前必须设好停止条件——错误率、P99、CPU 的熔断阈值，超了自动停。压测的目的是发现问题，不是把线上打穿。

全链路压测的挑战

单接口压测只能告诉你这个接口在当前脚本下能跑多少量，而真实瓶颈经常藏在链路深处：网关还很闲，库存服务开始排队；订单接口正常返回，MQ 已经堆积。全链路压测让流量沿真实业务链路走完整条路径，工程难点有三个：

  1. 数据隔离：压测流量不能污染真实订单、库存和账务。做法是压测账号加全链路透传的压测标，存储层用影子库/影子表接住压测写入，与真实数据物理分开。
  2. 流量标记与识别：从网关在请求头打标开始，每个服务、每条日志、每个监控维度都能认出压测流量，才能随时统计、随时止损。
  3. 护栏与观测：限流、熔断、降级在压测前确认生效；压测中同时盯应用指标、机器指标、数据库、缓存、MQ 堆积和慢 SQL，任何一环异常立即停。

业务复杂度没到时不必强上平台。先用 JMeter/wrk 把核心链路脚本跑清楚，能定位瓶颈、能保护数据、能快速停止，已经覆盖大部分容量评估场景。

指标解读的常见误区

最大的误区是看平均 RT。 平均值会被大量快请求拉低，把长尾完全掩盖。P99=500ms 的含义是 99% 的请求在 500ms 内返回，剩下 1% 的慢请求——缓存未命中、慢 SQL、GC 停顿——会长时间占用线程和连接。并发一高，长尾占满线程池，新请求开始排队，排队又推高延迟，雪崩的种子就是这样埋下的。看报告要同时看 P50/P90/P99 和错误率，核心链路样本量足够时再追 P999；样本只有几千个请求时，P999 很容易被偶发抖动带偏，不必过度解读。

另外两个常见错误：一是把实验室环境的压测结论直接套到生产——数据量、缓存命中率、网络环境不同，结论会整体失效；二是只看应用层指标，忘了对照数据库连接池、线程池队列、GC 等底层资源，找不到瓶颈的真实位置。压测结论必须附上当时的配置、数据规模和流量模型，脱离前提的数字没有意义。

小结

  • QPS/TPS/RT/并发数靠 Little 定律换算，但公式只在未饱和的线性区间成立，拐点要压出来。
  • 工具按”谁维护、进不进 CI”选；方法按真实业务模型设计，先备好停止条件。
  • 全链路压测的核心工程是影子库隔离、压测标透传和护栏观测。
  • 报告看分位数不看平均值，结论永远带上前提条件。