性能测试基础：吞吐量、QPS、TPS、并发用户数、响应时间等核心概念解析

大家好，我是你们这堂课的讲师。做性能测试这么多年，我见过太多人一上来就堆工具、跑脚本，结果数据出来了，自己都看不懂。说白了，性能测试不是跑个分就完事了，你得先搞清楚那些基础概念到底在说什么。

今天这一章，我们就来把这些核心概念掰开揉碎了讲清楚。嗯，我保证不枯燥，而且会把我这些年踩过的坑也一并分享给你。

1. 吞吐量（Throughput）—— 系统到底能干多少活？

吞吐量，是我个人最看重的指标之一。它衡量的是系统在单位时间内能处理多少请求或数据量。你可以把它想象成一条高速公路——单位时间内能通过多少辆车。

• 单位：通常用 请求数/秒、字节数/秒 或 事务数/秒 来表示。
• 场景：比如一个文件上传服务，吞吐量可能是 50 MB/s；一个 API 网关，可能是 2000 req/s。

2. QPS（Queries Per Second）—— 每秒查询率

QPS 这个词，在互联网圈子里几乎天天被挂在嘴边。它特指系统每秒能响应的查询次数。注意，这里强调的是「查询」，通常用于读多写少的场景，比如搜索引擎、商品列表页。

为什么会单独拎出来说？因为很多系统读和写的性能差异巨大。你写一条数据可能要锁表、写日志，但读一条数据可能直接从缓存里拿，快得多。

3. TPS（Transactions Per Second）—— 每秒事务数

TPS 是衡量系统处理完整事务的能力。一个事务可能包含多个操作，比如：登录（查询用户信息 + 生成 Token + 写日志），这就算一个事务。

在实际项目中，我习惯用 TPS 来衡量核心业务链路的性能。比如支付流程：扣库存、生成订单、调用支付网关、更新状态——这一整套下来，才算一个完整的事务。

指标	侧重点	典型场景
QPS	查询类操作	搜索、列表页
TPS	完整事务（含写操作）	下单、支付、注册

4. 并发用户数（Concurrent Users）—— 同时在线的人

并发用户数，指的是同一时刻正在与系统交互的用户数量。注意，是「正在交互」，不是「登录了但没操作」。

举个例子：一个直播间有 10 万人同时在线，但只有 1 万人在发弹幕、点赞。那并发用户数就是 1 万，而不是 10 万。

我刚开始做性能测试时，也犯过这个错。把注册用户数当成了并发用户数，结果压测脚本一跑，服务器直接挂了。嗯，教训深刻。

5. 响应时间（Response Time）—— 用户等多久？

响应时间，就是从用户发出请求到收到完整响应所花的时间。它通常包括：网络传输时间 + 服务器处理时间 + 数据库查询时间。

我个人习惯把响应时间分为三个维度来看：

• 平均响应时间：容易受极端值影响，比如一个请求卡了 10 秒，平均值就被拉高了。
• 中位数（P50）：一半请求比这个快，一半比这个慢。更稳定。
• 百分位数（P95/P99）：95% 或 99% 的请求都在这个时间内完成。这是用户体验的关键。

6. 这些概念之间的关系

说白了，这些指标不是孤立的。它们之间有一个经典的公式：

吞吐量（TPS） ≈ 并发用户数 / 平均响应时间

举个例子：如果并发用户数是 1000，平均响应时间是 0.5 秒，那 TPS 大约是 2000。如果响应时间变成 1 秒，TPS 就降到 1000 了。

所以，你想想看，优化响应时间，其实就是在间接提升吞吐量。这也是为什么我总说，性能调优要抓主要矛盾。

知识体系结构图

下面这张图，是我自己梳理的本章核心概念之间的关系，希望能帮你建立整体认知：

小结

这一章我们聊了五个核心概念：吞吐量、QPS、TPS、并发用户数、响应时间。它们就像性能测试的「五根手指」，缺一不可。你只有真正理解了它们，才能看懂压测报告，才能找到系统的瓶颈。

记住，不要死记硬背公式。下次你压测时，试着用这些概念去分析数据，你会发现，性能问题其实没那么神秘。