吞吐压测基础：吞吐量定义、TPS/QPS概念、压测核心指标、压测流程概览
吞吐压测，说白了就是看系统能扛多少活。
我做了这么多年性能测试，见过太多团队上来就压，压完一脸懵——数据出来了，但不知道意味着什么。嗯，这章咱们先把地基打牢。
一、吞吐量到底是什么？
吞吐量，英文叫 Throughput。简单理解就是：单位时间内系统能处理多少请求。
举个例子。你开了一家奶茶店，一小时能卖 50 杯。那 50 杯/小时，就是你的吞吐量。
在计算机世界里，吞吐量通常用这些单位衡量：
- 请求数/秒（最常用）
- 事务数/秒（TPS）
- 查询数/秒（QPS）
- 字节数/秒（网络吞吐）
核心观点：吞吐量不是越高越好，而是要在满足响应时间的前提下尽量高。
我在项目中遇到过，有个团队把吞吐量压到了 10000 TPS，但平均响应时间飙到了 5 秒。用户早跑了，这数据有啥意义？
二、TPS 和 QPS，别再傻傻分不清
这两个概念，面试常考，实际也容易混。我简单说清楚。
| 指标 | 全称 | 含义 | 典型场景 |
|---|---|---|---|
| TPS | Transactions Per Second | 每秒完成的事务数 | 下单、支付、转账 |
| QPS | Queries Per Second | 每秒完成的查询数 | 搜索、列表、详情页 |
你想想看，一个事务可能包含多个查询。比如用户下单：先查库存（1 个 Q），再扣库存（1 个 T），最后生成订单（1 个 T）。所以 TPS 通常小于 QPS。
我的习惯：做压测时，我一般先看 QPS 评估系统负载能力，再看 TPS 评估业务处理能力。两个指标要一起看，别只看一个。
三、压测核心指标，记住这五个
压测报告里指标很多，但真正核心的就这几个。我列出来，你记牢。
- 吞吐量（TPS/QPS）——系统能处理多少
- 响应时间（RT）——用户等多久
- 错误率——请求失败的比例
- 并发数——同时有多少请求
- 资源利用率——CPU、内存、IO 用了多少
这五个指标，缺一不可。我曾经见过一份报告，只写了 TPS 和 RT，没提错误率。结果一查，错误率高达 15%。那这份报告基本废了。
避坑指南：我曾经犯过一个错——只看平均响应时间。后来发现，平均 RT 是 200ms，但 99 分位 RT 是 2 秒。这意味着 1% 的用户体验极差。所以，一定要看 P99、P95 这些分位值。
四、压测流程概览，一张图说清楚
压测不是上来就开干。我总结了一套流程，用了好几年，基本没翻过车。
这张图我画了好几次才满意。你仔细看，流程不是线性的——第 7 步调优完，可能回到第 2 步重新写脚本，也可能回到第 4 步重新压。这是常态。
五、压测前的准备工作
别急着上工具。先问自己三个问题：
- 压什么？——核心接口还是全链路？
- 压多少？——目标 TPS 是多少？
- 压多久？——持续 5 分钟还是 1 小时？
我个人习惯，先定一个保守目标。比如线上预估 1000 TPS，我先压 500，看看系统反应。没问题再往上加。这叫「阶梯式加压」，比直接怼满要安全得多。
小技巧：压测前，先把监控搭好。至少要看 CPU、内存、磁盘 IO、网络带宽。不然数据出来了，你都不知道瓶颈在哪。
六、一个简单的压测示例
假设我们要压一个登录接口。用 JMeter 的话，脚本大概长这样：
// 伪代码示例，实际用 JMeter GUI 配置
Thread Group:
- 线程数: 100
- Ramp-Up: 10 秒
- 循环次数: 100
HTTP Request:
- 方法: POST
- URL: https://api.example.com/login
- Body: {"username":"test","password":"123456"}
监听器:
- 聚合报告
- 响应时间图
- 错误率统计跑完之后，看聚合报告里的 Throughput 字段。那就是你的吞吐量。
嗯，这里要注意：如果错误率超过 1%，先别管吞吐量，赶紧查错误原因。我见过有人压出 5000 TPS，但错误率 20%，还觉得系统很牛——那叫自欺欺人。
七、常见误区，我帮你列出来
- 误区一：吞吐量越高越好。错！要在响应时间达标的前提下谈吞吐量。
- 误区二：压测一次就够了。错！不同时段、不同数据量，结果可能天差地别。
- 误区三：只看平均值。错！P99 分位值才是用户体验的真相。
- 误区四：压测环境跟生产环境一样。错！硬件、网络、数据量都不一样，结果只能参考。
我曾经踩过的坑：有一次压测，我用了生产环境的 1/10 数据量，结果 TPS 很好看。上线后直接被打趴。后来才意识到，数据量大了，索引失效、锁竞争都来了。所以，压测数据量要尽量接近生产。
八、总结一下
吞吐压测，说白了就是回答三个问题：
- 系统能处理多少？——吞吐量
- 处理得快不快？——响应时间
- 处理得稳不稳？——错误率
这三个问题搞清楚了，压测报告就有说服力了。下一章，咱们会深入讲压测工具的选择和脚本编写技巧。不过那是后话，先把这章的基础吃透。
记住：没有扎实的基础，再花哨的分析都是空中楼阁。