压测基础概念：吞吐量、延迟、QPS/TPS与黄金三指标
各位同学，今天我们聊聊压测最核心的几个概念。说实话，我见过不少工程师上来就开压，结果连自己测的是什么都没搞清楚。嗯，这就像开车不看仪表盘——迟早要出事。
我个人习惯，在开始任何压测之前，先把这几个基础概念刻在脑子里。它们是你分析性能问题的「元语言」。
一、吞吐量（Throughput）—— 你到底能扛多少？
吞吐量，说白了就是「单位时间内能处理多少事」。在显存池的场景下，就是每秒能完成多少次显存分配+释放操作。
举个例子：
- 你的显存池每秒能处理 10 万次分配请求，那吞吐量就是 100K ops/s
- 如果压到 20 万次，系统开始报错或超时，那 10 万就是当前配置下的极限吞吐
关键点：吞吐量不是固定值。它跟并发数、请求大小、硬件配置都有关。我曾在项目中遇到过，换了个 NUMA 节点，吞吐量直接掉了 30%。
二、延迟（Latency）—— 快不快，看这个
延迟就是「从发请求到收到响应，花了多久」。注意，这里说的是单个请求的耗时，不是平均值。
为什么我强调「单个请求」？因为平均值会骗人。你想想看：
- 99% 的请求 1ms 完成
- 1% 的请求 1000ms 完成
- 平均延迟 ≈ 11ms —— 看起来还行？
但实际体验是，每 100 个用户里就有 1 个卡了 1 秒。这在线上是不可接受的。
我的习惯：看延迟，至少看 P50、P99、P999 三个分位值。P99 超过 10ms 的显存池，我一般直接打回优化。
三、QPS 与 TPS —— 别搞混了
这两个概念经常被混用，但严格来说有区别：
| 指标 | 全称 | 含义 | 显存池场景 |
|---|---|---|---|
| QPS | Queries Per Second | 每秒查询数 | 每秒发起的显存分配请求数 |
| TPS | Transactions Per Second | 每秒事务数 | 每秒完成的「分配+释放」完整事务数 |
在显存池压测中，我一般用 TPS。因为一次完整的显存使用周期是「分配→使用→释放」，这才是一个完整的事务。只测分配不测释放，就像只吃饭不洗碗——厨房迟早炸掉。
避坑指南：我曾经见过一个团队，QPS 压到 50 万，但 TPS 只有 10 万。为什么？因为分配快、释放慢，内存池被占满了，后续分配只能等。所以，只看 QPS 不看 TPS，等于自欺欺人。
四、压测的黄金三指标
做压测这么多年，我总结出三个必须盯死的指标。少了任何一个，你的压测报告就是废纸。
- 吞吐量（TPS） —— 系统能处理多少
- 延迟（P99 Latency） —— 用户感觉快不快
- 错误率（Error Rate） —— 系统稳不稳
这三者互相制约。你强行拉高吞吐，延迟就会飙升；你压到极限，错误率就会冒头。我个人的经验是：
- 错误率 < 0.1% 是底线
- P99 延迟 < 5ms 是优秀
- 吞吐量达到设计目标的 120% 才算达标
记住：没有错误率的压测是耍流氓。我曾经接手过一个系统，压测报告显示吞吐 20 万、延迟 2ms，看起来完美。结果一查日志，错误率 5% —— 所有错误请求都被压测工具自动重试了，根本没统计进去。
五、知识体系总览
下面这张图，是我自己画的知识结构。每次做压测前，我都会扫一眼，提醒自己别漏了什么。
六、实战中的一点体会
最后说点实在的。这些概念看起来简单，但真正用好它们，需要大量实践。我刚开始做压测时，也犯过只看平均延迟的错。后来被线上故障教育了几次，才老老实实把 P99 和错误率焊死在监控面板上。
嗯，今天就到这里。记住这三个指标，你的压测之路就稳了一半。
一个小建议：下次做压测前，先问自己三个问题——我的吞吐目标是多少？P99 延迟能接受多少？错误率容忍上限是多少？答不上来，就别开始。