3、压测基础理论：压测目标定义、吞吐量与延迟的关系、并发用户数与QPS/RPS的区别
3.1 压测目标定义：先问“为什么压”，再问“怎么压”
性能压测不是盲目地“把系统打满”，而是围绕明确的业务目标进行量化验证。在开始任何压测之前，必须回答三个核心问题：
- 容量目标：系统在正常水位下需要支撑多少业务量？例如“单机 2000 QPS”。
- 延迟目标：在目标吞吐下，响应时间必须控制在多少以内？例如“P99 ≤ 200ms”。
- 稳定性目标：持续压测多长时间不出现错误、不触发熔断？例如“30 分钟无 5xx 错误”。
实战建议：压测目标必须可量化、可复现。避免“系统要快”“要能抗住”这类模糊描述，应写成“在 1000 并发用户下，P99 延迟 ≤ 300ms，错误率 ≤ 0.1%”。
3.2 吞吐量与延迟的关系：跷跷板效应
吞吐量（Throughput）和延迟（Latency）是压测中最核心的一对矛盾指标。吞吐量通常以 QPS（Queries Per Second） 或 RPS（Requests Per Second） 衡量；延迟则包括平均延迟、P50、P90、P99 等分位值。
随着系统负载增加，吞吐量和延迟呈现典型的“跷跷板”关系：
- 线性区：负载较低时，吞吐量随并发线性增长，延迟保持稳定。
- 拐点区：当资源（CPU、内存、连接池）接近饱和，吞吐量增速放缓，延迟开始明显上升。
- 饱和区：系统过载，吞吐量不再增长甚至下降，延迟急剧恶化，出现排队和超时。
关键认知：压测的核心不是追求最大吞吐量，而是找到“可接受延迟下的最大吞吐量”。这个点通常被称为系统的 最佳工作点。
3.3 并发用户数与 QPS/RPS 的区别
这是压测中最容易被混淆的概念。简单来说：
- 并发用户数（Concurrent Users）：同时向系统发起请求的用户数量，是压测工具的“施压维度”。
- QPS / RPS：系统每秒实际处理的请求数量，是系统的“响应维度”。
两者通过 平均响应时间（ART） 关联，遵循 Little's Law：
Little's Law 公式：
例如：500 并发用户，平均响应时间 250ms（0.25s），则 QPS = 500 / 0.25 = 2000。
QPS = 并发用户数 / 平均响应时间（秒）例如：500 并发用户，平均响应时间 250ms（0.25s），则 QPS = 500 / 0.25 = 2000。
下表总结了三个核心指标的定义与用途：
| 指标 | 定义 | 单位 | 典型用途 |
|---|---|---|---|
| 并发用户数 | 同时在线或同时发起请求的用户数量 | 个 | 压测工具线程/协程数配置 |
| QPS | 系统每秒处理的查询/请求次数 | 次/秒 | 衡量系统处理能力 |
| RPS | 与 QPS 基本等价，更常用于 HTTP 接口 | 次/秒 | 接口吞吐量基准 |
| 平均响应时间 | 请求从发出到收到响应的平均耗时 | ms | 评估用户体验 |
常见误区：并发用户数 ≠ QPS。很多新手认为“1000 并发就是 1000 QPS”，实际上如果每个请求耗时 1 秒，1000 并发只能产生 1000 QPS；如果每个请求耗时 100ms，1000 并发可以产生 10000 QPS。两者相差巨大。
3.4 压测中的关键指标矩阵
一次完整的压测需要同时关注以下指标，才能全面评估系统健康状况：
| 指标类别 | 具体指标 | 健康阈值参考 | 说明 |
|---|---|---|---|
| 吞吐量 | QPS / RPS | 达到目标值 ±10% | 系统处理能力的核心指标 |
| 延迟 | P50 / P90 / P99 / Max | P99 ≤ 目标值，Max ≤ 3×P99 | P99 代表绝大多数用户的体验 |
| 错误率 | 5xx / 4xx / 超时 | ≤ 0.1% | 超过 1% 必须停止压测排查 |
| 资源利用率 | CPU / 内存 / 磁盘 / 网络 | CPU ≤ 80%，内存 ≤ 80% | 避免资源耗尽导致雪崩 |
| GC 与 Goroutine | GC 暂停时间 / Goroutine 数量 | GC 暂停 ≤ 10ms，Goroutine 无泄漏 | Go 应用特有的关键指标 |