压测指标详解：QPS、TPS、RT、P99延迟、吞吐量、并发用户数

做压测这么多年，我见过太多人一上来就盯着一个数字看。要么只看QPS，要么只看并发数。其实啊，压测就像体检，光量体温是不够的。你得把几个关键指标放在一起看，才能判断系统到底「健康不健康」。

今天我就把这几个核心指标掰开揉碎了讲。每个指标我都会告诉你：它是什么、怎么算、实际项目中怎么用、以及最容易踩的坑。

1. QPS 和 TPS：别再傻傻分不清

先说QPS，全称是 Queries Per Second，每秒查询数。TPS 是 Transactions Per Second，每秒事务数。

这两个词经常被混用，但严格来说不一样。QPS 偏重「读」操作，比如你查一次数据库、调一次接口，就算一个 Query。TPS 偏重「写」操作，或者更准确地说，是一个完整的事务——可能包含多个步骤。

举个例子：用户下单这个操作，在TPS视角里是一个完整事务。但在QPS视角里，它可能拆成了：查询商品、查询库存、创建订单、扣减库存、返回结果——这就算5个Query。

我的经验：在互联网公司做压测时，大家习惯说QPS。在金融、支付领域，大家更爱说TPS。你面试时如果能把这两个区别讲清楚，面试官会觉得你基本功扎实。

怎么算？公式很简单：

QPS = 总请求数 / 总耗时（秒）
TPS = 总事务数 / 总耗时（秒）

举个例子，你压了60秒，总共发了12000个请求，那QPS就是200。如果这些请求里包含了3000个完整事务，那TPS就是50。

避坑指南：我曾经遇到一个团队，压测报告上写着QPS 5000，结果上线后系统扛不住。后来一查，他们压测时只测了「查询」接口，没测「写入」接口。写入的TPS只有200。所以啊，压测一定要区分读写，不能混在一起说。

2. RT：响应时间，用户最直接的感受

RT 就是 Response Time，响应时间。说白了，就是用户点一下按钮，到看到结果，中间等了多久。

这个指标最直观，也最容易理解。但很多人只关注「平均响应时间」，这是个巨大的坑。

为什么？ 你想想看，平均响应时间200ms，听起来不错对吧？但实际情况可能是：90%的请求都在50ms内完成，剩下10%的请求拖到了1.5秒。用户如果恰好是那10%，体验就很差了。

所以我个人习惯，看RT一定要结合百分位来看。常用的有：

  • RT_mean：平均响应时间，仅供参考，别太当真
  • RT_max：最大响应时间，往往是个异常值，但能帮你发现极端情况
  • P50：中位数，一半请求比这个快，一半比这个慢
  • P90：90%的请求都在这个值以内
  • P99：99%的请求都在这个值以内，这是重点
注意：P99延迟不是「最慢的1%」，而是「保证99%的请求都能在多少毫秒内完成」。这个指标直接决定了你的SLA能不能达标。

3. P99延迟：压测中最容易被忽视的指标

P99延迟，全称是 99th Percentile Latency。它衡量的是：在100个请求里，排第99快的那个请求花了多长时间。

我见过太多团队，压测报告里只写「平均响应时间50ms」，结果上线后用户投诉说「卡死了」。一查P99，好家伙，800ms。平均响应时间被大量快速请求拉低了，但慢请求其实很多。

为什么会这样？ 因为系统的性能分布往往不是均匀的。可能有以下原因：

  • GC（垃圾回收）导致偶尔的停顿
  • 网络抖动
  • 数据库连接池不够用
  • 某些请求走了慢路径（比如缓存失效，查了数据库）

我建议你压测时，至少关注三个值：P50、P90、P99。如果P99比P50高出5倍以上，说明系统存在严重的「长尾延迟」问题，需要排查。

我的习惯：在压测脚本里，我会把P99延迟作为「红线指标」。比如要求P99 < 200ms，一旦超过就报警。平均响应时间可以放宽，但P99必须严格。

4. 吞吐量：系统到底能扛多少

吞吐量（Throughput），指的是单位时间内系统能处理的请求数量。单位可以是：

  • 请求/秒（req/s）
  • 事务/秒（tps）
  • 字节/秒（B/s）
  • 页面/秒（pages/s）

吞吐量和QPS很像，但侧重点不同。QPS更偏向「瞬时能力」，吞吐量更偏向「持续能力」。你压测10秒和压测10分钟，得到的吞吐量可能完全不同。

为什么？ 因为系统有「预热」和「衰减」的过程。刚启动时，缓存是空的，数据库连接还没建立，吞吐量会偏低。运行一段时间后，缓存命中率上来了，吞吐量会上升。再往后，如果内存泄漏或者连接池耗尽，吞吐量又会下降。

所以我做压测时，一般会分三个阶段：

  1. 预热阶段：跑1-2分钟，让系统进入稳定状态
  2. 稳定阶段：跑5-10分钟，记录吞吐量
  3. 压力阶段：逐步增加并发，找到吞吐量的拐点
避坑指南：我曾经压测一个网关服务，预热阶段吞吐量只有2000，跑了3分钟后涨到了5000。团队差点以为是系统有问题，后来发现是网关的DNS缓存生效了。所以啊，预热时间一定要给够，不然数据不准。

5. 并发用户数：不是越多越好

并发用户数（Concurrent Users），指的是同一时刻有多少个用户在访问系统。注意，是「同一时刻」，不是「一天的总用户数」。

很多人有个误区：觉得并发用户数越大越好。其实不是。并发用户数和系统性能之间，存在一个「拐点」。

举个例子：

并发用户数 QPS 平均RT P99延迟
100 2000 50ms 80ms
200 3800 52ms 85ms
500 4500 110ms 350ms
1000 4200 240ms 1200ms

看到没？并发从500增加到1000时，QPS反而下降了。这就是系统过载了——线程太多，上下文切换开销超过了处理能力。

最佳并发数，就是QPS达到最大值时的那个并发数。超过这个数，系统性能反而下降。

注意：并发用户数不是压测工具里的「线程数」。一个线程可以模拟多个用户（比如用循环），一个用户也可以对应多个线程（比如长连接）。搞清楚这个，你的压测数据才有意义。

6. 这些指标怎么配合使用？

单个指标看都是片面的。我一般会这样组合：

  • 看QPS/TPS：判断系统处理能力
  • 看RT/P99：判断用户体验
  • 看吞吐量：判断系统稳定性
  • 看并发用户数：找到最佳工作点

举个例子，你压测一个电商系统的下单接口：

并发用户数: 200
QPS: 1500
TPS: 300（因为一个下单事务包含5个请求）
平均RT: 130ms
P99延迟: 280ms
吞吐量: 300 TPS

这个数据说明什么？系统能扛住200个并发用户，每秒处理300个订单，99%的订单在280ms内完成。如果业务要求P99 < 200ms，那这个系统就不达标，需要优化。

我的经验：压测报告里，我会把「红线指标」标红。比如P99超过200ms标红，QPS低于1000标红。这样一眼就能看出问题在哪。

7. 一张图看懂压测指标关系

下面这张图，是我自己总结的压测指标关系图。你看完应该能明白，这些指标不是孤立的，而是互相影响的。

压测核心指标关系图 并发用户数 影响 影响 QPS/TPS RT/P99 决定 制约 吞吐量 并发用户数增加 → QPS先升后降，RT持续上升 → 吞吐量存在拐点

这张图的核心逻辑是：并发用户数是输入，QPS和RT是输出，吞吐量是最终结果。你调整并发数，QPS和RT会跟着变，最终决定系统的吞吐量。

嗯，指标就讲到这里。记住一句话：没有完美的指标，只有合适的组合。下次做压测，别只看一个数了。

最后提醒：压测指标不是死的。不同业务场景，关注的重点不一样。比如直播场景更关注P99延迟，批处理场景更关注吞吐量。灵活运用，才是真本事。

想要更多资料，联系可可

← 上一章 📖 返回目录 下一章 →