吞吐测试概述

吞吐测试，说白了就是看系统在单位时间内能处理多少活儿。我刚开始接触性能测试那会儿，总觉得这概念太简单——不就是算个TPS嘛。后来踩过几次坑才明白，吞吐量背后藏着的东西，远比表面看到的要深。

吞吐量的定义

吞吐量（Throughput），指的是系统在单位时间内成功处理的事务数、请求数或数据量。常见的衡量单位有：

指标	全称	含义
TPS	Transactions Per Second	每秒事务数，常用于数据库、交易系统
QPS	Queries Per Second	每秒查询数，常用于搜索引擎、API网关
RPS	Requests Per Second	每秒请求数，常用于Web服务器
bps	bits per second	每秒比特数，常用于网络带宽

嗯，这里要注意一个容易混淆的点。很多人把TPS和QPS混着用，其实在严格场景下它们是有区别的。TPS强调一个完整的事务——可能包含多次查询和写入；QPS只算查询次数。我在项目中见过有人拿QPS当TPS报给客户，结果上线后实际吞吐量对不上，挺尴尬的。

吞吐测试的重要性

为什么非要测吞吐量？你想想看，一个系统如果响应时间再快，但只能同时服务10个人，那它有什么用？吞吐量直接决定了系统的承载能力。

我个人习惯把吞吐测试比作「压力测试的照妖镜」。它暴露的问题往往很致命：

• 资源瓶颈——CPU打满、内存泄漏、连接池耗尽
• 锁竞争——数据库行锁、分布式锁、线程锁
• 架构缺陷——单点瓶颈、负载不均、缓存失效
• 配置失当——线程池太小、超时太短、队列溢出

我曾经接手过一个电商系统的压测任务。开发说系统能扛5000 QPS，结果我一测，到800 QPS就开始报超时。查了半天，发现是数据库连接池默认配了20个。嗯，这种坑在吞吐测试里太常见了。

吞吐测试与性能测试的关系

很多人把吞吐测试和性能测试划等号，其实不对。吞吐测试是性能测试的一个子集，它们的关系是这样的：

维度	性能测试	吞吐测试
关注点	响应时间、资源使用、稳定性	单位时间处理能力
典型场景	上线前全链路压测、容量规划	基准测试、对比测试、限流评估
输出指标	P99延迟、CPU利用率、错误率	TPS、QPS、RPS、带宽
测试方法	负载测试、压力测试、稳定性测试	基准测试、阶梯加压测试

说白了，性能测试是个大筐，吞吐测试是里面最核心的一块。我见过不少团队只测响应时间，不测吞吐量，结果上线后用户一多就崩。反过来，只测吞吐量不看响应时间也不行——你想想看，如果系统每秒能处理1万请求，但每个请求要等10秒，用户早跑了。

吞吐测试的核心逻辑

为了让你更直观地理解吞吐测试在整个性能体系中的位置，我画了一张图：

从这张图你能看出来，吞吐测试不是孤立存在的。它从负载测试、压力测试、稳定性测试中获取数据，最终输出给容量规划、限流设定和基线对比。我每次做吞吐测试，都会把这三个输出写进报告里，这样开发、运维、产品都能看懂。

吞吐测试的常见误区

做了这么多年吞吐测试，我总结了几条容易踩的坑：

1. 只看平均值——平均值会掩盖长尾问题。我习惯看P50、P90、P99三个分位值。
2. 预热不足——刚启动的系统，JIT还没编译完，缓存还没填充，这时候的吞吐量不准。我一般先跑2分钟预热再开始记录。
3. 忽略网络开销——内网压测和外网压测的吞吐量可能差一个数量级。我建议在目标环境或模拟环境下测试。
4. 单点压测代替全链路——只压一个接口不代表整个系统能扛住。我见过一个项目，单接口能到5000 QPS，全链路一跑直接崩在1000。