吞吐测试基础概念
吞吐测试，说白了就是看你的系统到底能扛多少活。我刚开始做性能测试那会儿，总觉得这玩意儿就是压一压、看看数字就完事了。后来踩过几次坑才明白——吞吐量是系统能力的核心指标，不懂它，优化就无从谈起。
什么是吞吐量
吞吐量（Throughput）指的是单位时间内系统成功处理的请求数量。你可以把它想象成一条高速公路——车流量就是吞吐量，路况就是系统状态。
举个例子：一个电商网站的登录接口，1分钟内成功处理了1200次登录请求，那它的吞吐量就是1200 req/min，或者换算成20 req/s。
核心公式：
吞吐量 = 成功处理的请求总数 / 测试持续时间
注意是「成功处理」——那些超时、报错、返回500的请求，统统不算。
TPS 与 QPS 的定义
这两个概念经常被混用，但严格来说有区别。我个人习惯这样区分：
| 指标 | 全称 | 含义 | 典型场景 |
|---|---|---|---|
| TPS | Transactions Per Second | 每秒完成的事务数 | 数据库事务、订单提交、支付流程 |
| QPS | Queries Per Second | 每秒完成的查询数 | 读接口、搜索请求、页面加载 |
一个事务可能包含多个查询。比如下单操作：先查库存（1个Q），再扣库存（1个Q），最后生成订单（1个Q）——这3个查询合起来才算1个TPS。
我的经验：在互联网公司，大家更习惯说QPS，因为大部分场景是读多写少。但在金融、支付领域，TPS才是硬指标——一个事务没做完，钱可能就丢了。
吞吐量与延迟的关系
这是性能测试里最经典的一对冤家。你想想看：系统处理能力有限，请求来得越多，每个请求排队的时间就越长，延迟自然就上去了。
我画了一张图，帮你直观理解这个关系：
看到那条红色曲线了吗？在吞吐量较低时，延迟基本平稳。但一旦超过某个阈值（拐点），延迟就像坐火箭一样往上窜。我曾经帮一个客户排查线上问题，他们的QPS从2000涨到2500，延迟就从50ms飙到了800ms——这就是典型的拐点效应。
避坑指南：千万不要只看平均延迟！我曾经被平均延迟骗过——系统在低负载时延迟10ms，高负载时部分请求延迟5秒，平均下来才200ms，看起来还行。但实际上，那5秒的请求已经让用户体验崩溃了。建议同时关注P99、P999延迟。
吞吐测试的目标与意义
吞吐测试不是跑个数字就完事了。它的核心目标，我总结为三点：
- 摸清家底：知道系统到底能扛多少并发，极限在哪里
- 找到瓶颈：是CPU扛不住了？数据库慢了？还是网络带宽不够？
- 指导扩容：什么时候该加机器？加几台？吞吐测试给你数据支撑
我记得有一次做双十一前的压测，发现系统在3000 QPS时CPU才用到60%，但延迟已经飙到2秒了。查了半天，原来是连接池配小了——线程都在等数据库连接。这就是吞吐测试的价值：它告诉你问题在哪，而不是让你瞎猜。
吞吐测试的典型应用场景：
- 上线前的容量评估
- 架构改造前后的对比验证
- 线上突增流量的风险评估
- SLI/SLA指标的制定依据
说白了，吞吐测试就是给系统做一次「体能测试」。你不知道它能跑多远、能扛多重，就贸然上线——那跟闭着眼睛开车有什么区别？
一个小建议：做吞吐测试时，别只盯着最大值。我习惯看三个数：稳定值（系统能长期保持的吞吐量）、峰值值（短时间能冲到的上限）、以及拐点值（延迟开始恶化的临界点）。这三个数比一个孤零零的「最大QPS」有用得多。