吞吐压测概述：从入门到实战
吞吐压测，说白了就是看看你的系统到底能扛多少活。
我刚开始做性能测试那会儿，总觉得这玩意儿挺玄乎。后来踩的坑多了，才明白它其实就是个「压力测试」——给系统不断加码，直到它撑不住为止。嗯，这里要注意，不是把它搞崩，而是找到那个「临界点」。
什么是吞吐压测
吞吐压测，全称是「吞吐量压力测试」。它模拟大量用户同时访问你的系统，看看系统每秒能处理多少请求。
举个例子：你开了一家奶茶店。吞吐压测就是——让100个人同时来买奶茶，看你的店员1分钟能做多少杯。如果只能做10杯，那你的「吞吐量」就是10杯/分钟。
我个人习惯把吞吐压测分成两类：
- 单接口压测：只测一个API，比如登录接口
- 混合场景压测：模拟真实用户行为，比如登录→浏览→下单→支付
我在项目中遇到过最典型的场景：上线前老板问「系统能支持多少人在线？」。这时候，吞吐压测就是唯一能给出准确答案的手段。
为什么需要吞吐压测
你想想看，没有压测就上线，就像没试过刹车就开车上路。风险太大了。
具体来说，吞吐压测能帮你解决三个核心问题：
- 容量规划：系统到底能扛多少并发？需要多少台服务器？
- 瓶颈定位：是数据库慢了？还是代码写得烂？压测一跑，原形毕露
- 稳定性验证：系统在高负载下会不会崩？会不会内存泄漏？
核心观点：吞吐压测不是为了证明系统有多强，而是为了找到它的「天花板」。
我记得有一次，一个客户说他们的系统能支持1万并发。结果我一压测，3000并发就挂了。后来发现是数据库连接池配得太小。你看，不测不知道，一测吓一跳。
吞吐压测的核心指标
做吞吐压测，你得盯住三个关键指标。我管它们叫「铁三角」：
| 指标 | 全称 | 含义 | 我的经验值 |
|---|---|---|---|
| QPS | Queries Per Second | 每秒查询数 | 读多写少的系统重点关注 |
| TPS | Transactions Per Second | 每秒事务数 | 金融、电商系统重点关注 |
| 并发数 | Concurrency | 同时处理的请求数 | 跟QPS/TPS是「相爱相杀」的关系 |
QPS：每秒查询数
QPS 衡量的是系统每秒能处理多少个查询请求。说白了就是「问问题」的速度。
举个例子：你刷抖音，每刷一次就是一次查询。如果抖音的QPS是100万，那就意味着每秒有100万人在同时刷。
我曾经帮一个资讯类App做过压测。他们的QPS目标是5000，结果一测只有800。查了半天，发现是缓存策略有问题——每次请求都去查数据库，能不慢吗？
TPS：每秒事务数
TPS 比 QPS 更「重」一些。一个事务可能包含多个操作。比如你在淘宝下单：
- 查询商品信息（1个QPS）
- 扣减库存（1个QPS）
- 生成订单（1个QPS）
- 扣款（1个QPS）
这4个QPS加起来，才算1个TPS。
避坑指南：我曾经犯过一个错误——把QPS当TPS报给老板。结果上线后系统扛不住，差点背锅。记住：TPS才是衡量业务处理能力的真实指标。
并发数：同时在线的人数
并发数，就是同一时刻有多少个请求在「排队等处理」。
这里有个容易混淆的点：并发数 ≠ QPS。举个例子：
- 并发数1000，QPS可能是500
- 并发数500，QPS也可能是1000
为什么会这样？因为每个请求的处理时间不一样。处理得快，QPS就高；处理得慢，QPS就低。
我习惯用这个公式来估算：
QPS = 并发数 / 平均响应时间（秒）比如并发数是1000，平均响应时间是0.5秒，那QPS就是2000。
三个指标的关系
这三个指标不是孤立的。它们之间的关系，我用一张图来说明：
重要提醒：别被数字迷惑。我见过太多人只看QPS，不看响应时间。QPS再高，如果响应时间超过3秒，用户体验就是灾难。
实战中的取舍
做吞吐压测，你得学会「抓大放小」。我个人习惯这样定目标：
- 读多写少的系统（比如资讯App）：重点看QPS
- 事务型系统（比如支付、电商）：重点看TPS
- 高并发场景（比如秒杀）：重点看并发数
但不管看哪个指标，有一条铁律：响应时间不能超过业务容忍上限。
我曾经帮一个金融系统做压测。他们的TPS目标是2000，但要求响应时间不超过200毫秒。结果一测，TPS到1500时响应时间就飙到500毫秒了。最后只能加服务器，把TPS压到1800，响应时间控制在180毫秒。你看，这就是取舍。
小结
吞吐压测，说白了就是回答三个问题：
- 系统能处理多少请求？（QPS/TPS）
- 能同时服务多少人？（并发数）
- 响应够不够快？（响应时间）
这三个问题搞清楚了，系统的「天花板」也就摸清了。嗯，这就是吞吐压测的核心。
一句话总结：吞吐压测不是炫技，而是为了让你知道——系统什么时候会崩，以及怎么避免它崩。
想要更多资料，联系可可