一、压测基础：吞吐量、QPS、TPS、并发用户数、响应时间等核心指标定义与关系
做性能测试这些年，我见过太多人一上来就堆机器、调参数，结果连最基本的指标都没搞清楚。说白了，压测不是玄学，它是一套可量化的工程方法。今天我们就从最核心的几个指标说起。
1.1 吞吐量（Throughput）——系统到底能扛多少？
吞吐量，顾名思义，就是系统在单位时间内能处理多少请求。它通常用 TPS（每秒事务数）或 QPS（每秒查询数）来衡量。
我个人习惯把吞吐量比作「高速公路的车流量」。路宽、限速高、车跑得快，单位时间通过的车就多。系统也一样——CPU、内存、IO、网络，哪个环节卡住，吞吐量就上不去。
核心公式：
吞吐量 = 并发用户数 / 平均响应时间
这个公式很关键，后面我们会反复用到。
我在项目中遇到过一个问题：某电商大促时，系统吞吐量突然掉了一半。查了半天，发现是数据库连接池配置太小，线程都在等连接。嗯，这就是典型的「吞吐量瓶颈」——不是机器不够，是资源分配不合理。
1.2 QPS 与 TPS——别再傻傻分不清
很多新手问我：QPS 和 TPS 到底有什么区别？
我一般这么解释：
- QPS（Queries Per Second）：每秒查询数。适用于读多写少的场景，比如搜索引擎、内容展示。
- TPS（Transactions Per Second）：每秒事务数。适用于写操作或完整业务流程，比如下单、支付。
举个例子：你打开一个商品详情页，浏览器发起了 10 个请求（图片、CSS、JS、接口数据）。这 10 个请求算 10 个 QPS。但如果这 10 个请求共同完成了一次「浏览商品」这个事务，那它只算 1 个 TPS。
我的建议：
压测时，如果系统是纯查询接口，用 QPS 就够了。如果是涉及写库、多步骤的业务流程，一定要用 TPS。我曾经见过有人用 QPS 去压支付接口，结果数据完全失真——因为一个支付事务可能包含 5-8 个接口调用。
1.3 并发用户数——不是越多越好
并发用户数，指的是同一时刻系统正在处理的用户请求数量。注意，是「正在处理」，不是「已连接」。
很多人以为并发用户数越大，系统压力越大。其实不然。你想想看：如果每个请求响应时间都是 1 秒，那 100 个并发用户和 1000 个并发用户，对系统的压力差别巨大。但如果响应时间只有 1 毫秒，那 1000 个并发用户可能也没什么感觉。
为什么会这样？因为并发用户数、响应时间、吞吐量三者是联动的。我习惯用一个公式来理解：
并发用户数 = 吞吐量 × 平均响应时间这个公式反过来也成立：吞吐量 = 并发用户数 / 平均响应时间。所以，并发用户数只是一个中间变量，真正决定系统压力的是「吞吐量 × 响应时间」这个乘积。
避坑指南：
我曾经犯过一个错误：压测时只关注并发用户数，忽略了响应时间。结果并发从 100 升到 500，响应时间从 50ms 飙到了 2s，吞吐量反而下降了。后来我才明白——并发用户数不是目标，它是手段。我们的目标是找到系统在「可接受响应时间」下的最大吞吐量。
1.4 响应时间——用户感知的「快」与「慢」
响应时间，就是用户从发出请求到收到完整响应所花的时间。它通常包括：
- 网络传输时间：数据在客户端和服务器之间来回的时间
- 服务端处理时间：CPU 计算、数据库查询、IO 读写等
- 排队等待时间：请求在队列里等着被处理的时间
我一般用「百分位响应时间」来评估，而不是平均值。为什么？因为平均值会被极端值拉偏。比如 99% 的请求都在 100ms 内完成，但有一个请求花了 10s，平均值可能就变成了 200ms——这完全掩盖了真实情况。
我个人习惯看 P99（99% 分位） 和 P95（95% 分位）。如果 P99 在 200ms 以内，用户体验基本没问题。如果 P99 超过 1s，那就得优化了。
1.5 核心指标关系图
下面这张图，是我自己总结的压测核心指标关系。你看一眼就能明白它们是怎么互相影响的：
从这张图你能看到：并发用户数增加，吞吐量和响应时间都会上升。但响应时间一旦超过某个阈值，吞吐量反而会下降——这就是系统进入了「过载区」。我把它叫做「拐点」，找到这个拐点，就是压测的核心目标。
1.6 实战中的指标取舍
说了这么多，到底该关注哪些指标？我列个优先级：
| 优先级 | 指标 | 为什么重要 |
|---|---|---|
| 1 | P99 响应时间 | 直接影响用户体验，也是系统健康度的晴雨表 |
| 2 | 吞吐量（QPS/TPS） | 衡量系统处理能力，决定能否支撑业务峰值 |
| 3 | 错误率 | 超过 0.1% 就要警惕，超过 1% 必须停压排查 |
| 4 | 资源利用率 | CPU、内存、IO、网络，哪个先到瓶颈？ |
| 5 | 并发用户数 | 作为参考，不是目标 |
我的经验：
压测时，我一般先定一个「可接受的响应时间」阈值（比如 P99 ≤ 200ms），然后逐步增加并发用户数，直到响应时间超标或错误率上升。这时候记录下来的吞吐量，就是系统的「最大安全吞吐量」。记住，是「安全」的，不是「极限」的——极限值往往伴随着高延迟和高错误率，生产环境用不上。
1.7 避坑指南：新手最容易犯的 3 个错误
- 只看平均值：平均值会骗人。我见过一个系统，平均响应时间 50ms，但 P99 是 5s——这意味着 1% 的用户在忍受 5 秒的延迟。所以，请务必看百分位。
- 混淆 QPS 和 TPS：压测前先搞清楚你的业务场景。如果是下单、支付这种写操作，用 TPS；如果是搜索、浏览这种读操作，用 QPS。混用会导致结论完全错误。
- 忽略预热：系统刚启动时，JIT 编译、缓存填充都没完成，这时候的压测数据是假的。我习惯先跑 5-10 分钟预热，等指标稳定了再开始记录。
嗯，以上就是压测基础的核心内容。这些指标就像医生的听诊器——你不需要天天用，但必须知道怎么看、怎么用。下一节我们会深入具体的压测工具和实战案例，到时候再细聊。
一句话总结：
压测不是比谁的数字大，而是找到系统在「可接受响应时间」下的「最大吞吐量」。并发用户数只是手段，不是目标。
想要更多资料，联系可可