2. 压力测试基础概念：并发、吞吐量、延迟、资源利用率
在真正动手压测以前，先把几个核心概念理清楚。这就像盖房子前先看懂承重墙图纸——后来踩的坑，多半是当初概念没吃透。我去年讲过一个课，还是把当年啃英文文档踩的坑掰开来讲，下面这些理解，都是从生产环境里拿真金白银换回来的。
并发（Concurrency）
并发不是简单的“同时发生”，这个词有点绕。我记得第一次接触压力测试时，我对“并发”的理解特别模糊——以为就是同时发起多少请求。
其实不是这样的。并发的本质是系统同时处理的活跃连接数。你想想看，请求一进来不会立即离开，它要排队、处理、等待 IO。这个时候，系统手里握着一堆没结束的连接，这些连接的总数就叫并发。
我习惯把并发拆成三层来看：
- 在线并发：用户登录了但还没操作，比如打开页面去倒水了。这类并发不产生实际压力，但占会话。
- 并发连接：TCP 连接建起来了，请求可能还在路上。这是网络层面看到的并发。
- 并发请求：服务端真正收到并开始处理的请求。这才是压测关心的重点。
一个建议：定义压测场景时，务必写明并发指的是哪一层。否则测试结果根本没办法对齐。我见过的压测报告里，有说并发5000的，实际只是建连接没发请求，那跟压空气没区别。
吞吐量（Throughput）
吞吐量说的是单位时间内系统能处理多少个请求。说白了，产能即吞吐。
我个人习惯用 QPS（每秒查询数）来评估系统吞吐。但要注意，QPS 和 TPS 不是一回事：
| 指标 | 含义 | 典型场景 |
|---|---|---|
| QPS | 每秒查询次数，侧重读操作 | 商品列表、搜索接口 |
| TPS | 每秒事务数，侧重完整业务闭环 | 下单、支付、注册流程 |
| 吞吐带宽 | 每秒传输数据量 | 文件上传、视频流接口 |
有一个坑我踩过好几次：别只看服务端的 QPS，要看客户端的实际完成率。举个例子，我压过一个订单系统，服务端 QPS 已经打到 2000 了，但客户端观察到的实际完成率只有 1800。为什么？因为中间有网络丢包重传、连接池排队、内存攒着没发出去。这种隐性损耗，不放在客户端侧统计根本就发现不了。
吞吐量不是越高越好。你持续压到吞吐量拐点，再往上加并发，吞吐反而暴跌——那就是系统崩溃的前兆了。
延迟（Latency）
延迟，指的是一个请求从发出去到收到响应，中间花了多少时间。这个指标最直观，但也最容易骗人。
我遇到过最头疼的情况就是，平均延迟看起来不错——80ms 嘛，挺好。但某个接口高并发时，P99 延迟飙到了 1800ms。真上线以后，头部大客户正好中招，体验差得不行。后来我养成了一个习惯：永远看延迟分布。
一般我用这几个分位：
- P50（中位数）：一半的请求比这个快，一半比这个慢。能反映整体水平。
- P90：90% 的请求比这个值快。如果 P90 偏高，说明多数用户都在被拖累。
- P99：99% 的请求都能压在这个值以内。这通常是系统真实的承载上限附近的感受。
- 最大延迟：看它的稳定性。如果最大延迟忽高忽低，说明系统内部有抖动。
小心“平均延迟陷阱”。我曾经把一个接口平均延迟压到 50ms，觉得稳了。结果业务高峰期，P99 直接突破 2 秒。你想想看，这个平均数字还有什么意义？
资源利用率（Resource Utilization）
压测最后都要落到资源上。你系统能不能扛住，最终还是看 CPU、内存、网络 IO、磁盘 IO 这些硬件撑不撑得住。
我一般记住这几个阈值经验：
- CPU 使用率：超过 70% 就要警惕了。很多系统在 80% 以上开始出现内核调度抖动，延迟也跟着涨。
- 内存：不是看剩余内存，是看 GC 频率。JVM 堆内存如果 1 分钟内 Full GC 超过 3 次，那压测必须停。
- 网络 IO：不要只看带宽。要看小包数量，很多压测工具默认发大包，实际业务里多是短连接小包，那才是真正的瓶颈。
- 磁盘 IO：如果说有什么能悄悄磨死一个系统，那就是日志写入。我亲眼见过一个服务 CPU 才 20%，吞吐死活上不去，最后发现是日志落盘把 IO 打满了。
关联视角：资源利用率不能单独看。必须跟吞吐量和延迟放在同一张时间线上，你才能判断——系统变慢是因为资源满了，还是因为代码有瓶颈。
这四个概念其实是一体的。我给你画了一张图，把它们之间的关系串起来：
这张图你多看几遍。每次压测得出的数据，都要往这四个维度上做映射。缺了任何一个，你看到的结果都可能是有偏差的。
嗯，基础概念就讲到这里。记住，压测不是看一个数字就完事的事。每一组数据都有它背后的物理含义。后面做方案设计时，我会反复用到这里讲到的框架。