一、压测基础：吞吐量、QPS、TPS、并发用户数、响应时间等核心指标定义与关系

做性能测试这么多年，我见过太多人一上来就堆机器、调参数，结果连最基本的指标都没搞清楚。说白了，你连「快」和「慢」的标准都没定好，怎么调优？今天我们就把这些基础概念掰开揉碎了讲清楚。

先给个全景图。下面这张图是我自己总结的压测核心指标关系，你看一眼就能明白个大概：

嗯，这张图你得记住。它讲的是：并发用户数是压测的「输入」，而QPS/TPS、响应时间、吞吐量是压测的「输出」。它们之间互相影响，不是孤立存在的。

并发用户数，不是「在线用户数」。我见过太多人把这两个搞混了。在线用户只是登录了系统，可能正在喝茶看报表；并发用户是同时发起请求的那批人。

举个例子：一个电商系统有10万在线用户，但真正在「双11」秒杀时同时点「立即购买」的，可能只有5000人。这5000才是并发用户数。

关键点：并发用户数 = 单位时间内发起请求的用户数量。它不是越大越好，而是要看系统能扛住多少。

这两个经常被混用，我来说清楚。

QPS（Queries Per Second）：每秒查询数。一般用在读场景，比如搜索、列表查询。
TPS（Transactions Per Second）：每秒事务数。一个事务可能包含多个请求，比如「下单」这个事务，包含查询库存、扣减库存、生成订单、支付等多个步骤。

我在项目中遇到过这样的情况：某团队说他们的系统TPS能达到5000，结果一细问，他们测的是QPS。为什么会有这种混淆？因为很多压测工具默认把每个HTTP请求算作一个「事务」。你想想看，如果每个请求都算事务，那TPS和QPS就没区别了。但真正的业务场景里，一个事务往往包含多个请求。

我的建议：压测前先定义好「事务」的边界。比如「用户注册」这个事务，包含填写信息、提交、发送验证码、验证成功——这才算一个完整事务。别把单个接口的QPS当成TPS来汇报，容易闹笑话。

响应时间，就是用户从发出请求到收到完整响应所花的时间。注意是「完整响应」，不是「第一个字节」。

响应时间通常看三个值：

我曾经帮一个金融客户调优，他们只看平均响应时间，觉得50ms挺快。结果我一看TP99，好家伙，直接飙到2秒。为什么？因为有个慢查询拖了后腿，平均一下看起来还行，但实际用户体验很差。

注意：不要只看平均值！平均值会骗人。重点关注TP95和TP99，它们才是用户真实体感的反映。

吞吐量，说白了就是系统在单位时间内能处理多少请求或数据量。单位可以是：

吞吐量和QPS的关系，有点像「总产量」和「单位产量」。QPS是每秒能处理多少查询，吞吐量是整体能处理多少。在压测报告里，我习惯把吞吐量作为宏观指标，QPS/TPS作为微观指标。

指标	定义	典型单位	与并发用户数的关系
并发用户数	同时发起请求的用户数量	个	—
QPS	每秒查询数（读场景）	次/秒	并发用户数 ↑ → QPS ↑（线性增长，直到瓶颈）
TPS	每秒事务数（写/混合场景）	个/秒	并发用户数 ↑ → TPS ↑（受事务复杂度影响）
响应时间	请求发出到收到完整响应的时间	毫秒(ms)	并发用户数 ↑ → 响应时间 ↑（非线性增长）
吞吐量	单位时间内处理的请求/数据总量	请求/秒或 MB/秒	并发用户数 ↑ → 吞吐量 ↑（达到上限后下降）

这里有个经典公式，我建议你刻在脑子里：

并发用户数 = QPS × 平均响应时间（秒）

举个例子：如果QPS是1000，平均响应时间是200ms（0.2秒），那么并发用户数 = 1000 × 0.2 = 200。也就是说，200个并发用户就能让系统达到1000 QPS。

反过来，如果你知道并发用户数是500，平均响应时间是300ms，那QPS = 500 / 0.3 ≈ 1667。这个公式在压测规划时特别有用。

做压测这么多年，我总结了几条血泪教训：

别把「并发」等同于「多线程」。我曾经见过一个团队，用1000个线程发请求，以为就是1000并发。结果每个线程发完一个请求就等响应，实际同时发请求的只有几十个。真正的并发，是同一时刻发出去的请求数。
响应时间要分阶段看。网络延迟、排队等待、服务处理、数据库查询——每一段都可能成为瓶颈。我习惯在压测时加上链路追踪，看看时间到底花在哪。
吞吐量不是越高越好。当吞吐量接近系统上限时，响应时间会急剧恶化。你想想看，如果为了多处理10%的请求，响应时间从200ms飙到2秒，用户早就跑了。

一句话总结：压测不是比谁的数字大，而是找到系统在「可接受响应时间」下的「最大吞吐量」。这才是性能调优的真正目标。

好了，这一章的基础概念就讲到这里。记住这些指标和它们的关系，后面的调优实战才能有的放矢。