3. 吞吐测试核心指标
做吞吐测试，你得先搞清楚一件事。
你测的到底是什么？
很多人一上来就找工具，装环境，压了一堆数据，结果一问——他连TPS和QPS的区别都说不清。这其实挺常见的。我刚带团队那会儿，有个组员拿着报告跟我说：“系统吞吐量5000”，我一看，他拿QPS当TPS报了，两个差了十倍。
嗯，所以咱们先把这四个核心指标掰扯清楚。
3.1 TPS 与 QPS：一对“双胞胎”
TPS：Transactions Per Second，每秒事务数。
QPS：Queries Per Second，每秒查询数。
这两兄弟最容易搞混。我个人的理解很简单：TPS 侧重“有没有改数据”，QPS 侧重“有没有查数据”。
举个例子。你登录淘宝，输入密码，点“登录”。
- 这个动作涉及用户校验、生成、写日志——这是一个事务。系统TPS +1。
- 如果登录后什么都没干，后台没有新的查询请求，那QPS不会动。
但你打开商品详情页，浏览一遍——这个行为不写数据，只是读。QPS +1，但TPS不增加。
实战判断法：
我习惯用一个简单方法判断：如果请求会修改数据库，就算TPS；如果只是读，就算QPS。
当然，有些场景下两者会重合，比如一个写事务也包含多次查询。这时我更关注TPS，因为它是业务的关键路径。
具体到测试，如果系统是纯查询模块（比如搜索引擎），你盯着QPS就够了。如果是混合型系统，比如电商下单、支付流水，那核心指标一定是TPS。
我踩过一个坑。有个支付系统，我压测时只看QPS，飙到2万多，满意得不行。结果一上线，数据对不上。后来排查发现，QPS高是因为缓存层扛住了读请求，但写数据库的事务积压了，真实TPS不到2000。从那以后，我再也不敢只看单一指标了。
3.2 TPS与QPS的关系公式
你可以记一个简单公式：
TPS ≈ QPS × 写操作占比
QPS = 读操作 + 写操作（单次请求拆分）举个例子。如果一个系统80%是读，20%是写。
- QPS压到5000。
- 写请求占比20%，也就是1000个写请求/秒。
- 但如果一个写请求要完成三个数据库写操作，那么实际的TPS可能是1000，而不是3000。
为什么？因为TPS计算的是“业务事务”的粒度，不是数据库操作的粒度。
| 指标 | 定义 | 典型场景 | 我用的判断标准 |
|---|---|---|---|
| TPS | 每秒完成的事务数 | 下单、支付、转账 | 写操作或混合操作 |
| QPS | 每秒完成的查询数 | 商品搜索、内容浏览 | 纯读或单次请求 |
3.3 带宽：最容易忽略的瓶颈
带宽往往是被忽略的那个。
为什么？因为大部分人压测都在本地或内网，带宽根本不是问题。但到了生产环境，尤其公网场景，带宽就是第一道坎。
我遇到过一件事。有次给一家客户做压测，服务器端CPU和内存都只有30%，TPS死活上不去。我盯着网络监控看，发现网卡流量到了1Gbps，已经逼近上限了。后来一问，客户用的共享带宽，1Gbps就是极限。我改用压缩传输，TPS直接翻倍。
带宽的计算公式很简单：
吞吐量（bps） = 平均包大小（bit） × 每秒包数量或者更直观一点：
假设单次请求+响应是2KB，带宽是100Mbps（约12.5MB/s）。
理论最大 QPS = 12.5MB/s ÷ 2KB = 约6400。实战建议：测试前，先算一下你的带宽上限。如果你的响应包很大（比如图片、视频），带宽会先成为瓶颈。
3.4 并发数：压测的“油门”
并发数就是你一次性发起多少个连接。它不是吞吐量本身，而是影响吞吐量的关键因素。
我记得有一次压测一个API，并发从100加到500，TPS涨得很快。但到了800并发，TPS不涨反跌。这叫“拐点”——系统已经过载了。
并发数与吞吐量的关系：
- 线性增长区：并发增加，吞吐同步增加。
- 平稳区：并发增加，吞吐不再涨，说明资源饱和。
- 下降区：并发继续增加，吞吐下降，系统开始排队、超时。
你想想看，一旦进入下降区，就是典型的“用户增多但体验变差”。
避坑指南：我曾经犯过一个经典错误——用并发数当吞吐量去汇报。老板问：“系统能支持多少并发？”我说2000。后来才发现，2000并发时TPS只有500。并发数和吞吐量不是一回事。
3.5 四者关系：一张图看懂
为了方便理解，我画了一张关系图。你看完应该就能把四个指标串起来了。
3.6 实战：怎么用这些指标？
知道了定义没用，关键是怎么用。
我个人的测试流程是：
- 先估算业务模型：单次请求平均包多大？写操作占比多少？
- 再算带宽上限：如果包太大，先优化传输，再压测。
- 然后设定并发目标：比如从100并发开始，每次加50，直到找到拐点。
- 最后看TPS和QPS曲线：找到稳定区，看是否满足业务目标。
一个小技巧：压测时，最好把四者显示在同一个仪表盘上。当并发增加但TPS不涨时，立刻看带宽——如果带宽已经打满，说明要加网卡或压缩数据了。
3.7 常见误解：我见过最多的三种
在这个领域待久了，我见过太多人犯同样的错。列出来，你避一下：
- 误解一：TPS高就是系统好。 不对。如果TPS高但错误率也高，或者响应时间巨长，那就是牺牲质量换数量。
- 误解二：QPS和TPS可以互相换算。 不能。它们关注不同的维度，除非你的系统全是纯查询或全是纯写入。
- 误解三：并发数越高越好。 错。超过拐点后，并发数越高，系统越烂。
我记得有次一个同事信誓旦旦地说：“我压到3000并发，TPS有8000，系统很牛。”我说：“3000并发，TPS才8000？平均一个并发只有2.67笔/秒，这叫低效，不叫牛。”
所以啊，一定要把这些指标结合起来看。
3.8 总结：一张表格帮你记忆
| 指标 | 关注什么 | 我常用的测试值 | 踩坑提醒 |
|---|---|---|---|
| TPS | 业务事务处理能力 | 2000~10000 取决于系统 | 别把数据库操作当TPS |
| QPS | 查询请求处理能力 | 3000~50000 常见 | 与TPS混用容易错 |
| 带宽 | 数据通道容量 | 1Gbps~10Gbps | 内网测试容易忽略 |
| 并发数 | 同时在线连接数 | 500~5000 | 不是越多越好 |
这四个指标，说白了就是你的系统的“体检项目”。你不能只看一项，也不能完全不看。下一轮压测前，先问问自己：这四个指标，你都盯住了吗？