📚 课程目录第2章压测方法论

2. 压测方法论：负载测试、压力测试、稳定性测试、容量测试的区别与联系

在 Prometheus 采集作业平台的性能基准测试中，明确不同压测类型的定义、目标与适用场景，是制定有效测试方案的前提。负载测试、压力测试、稳定性测试与容量测试虽然同属性能测试范畴，但其关注点、施加策略与通过标准存在本质差异。本节从定义、目标、关键指标与典型场景四个维度进行系统对比。

2.1 四种压测类型的核心定义与目标

测试类型	核心定义	主要目标	典型问题发现
负载测试	在预期或略高于预期的并发负载下，验证系统能否持续稳定运行	验证系统在正常/峰值负载下的响应时间、吞吐量与资源利用率是否满足 SLA	响应时间劣化、资源瓶颈、配置不合理
压力测试	持续增加负载直至系统失效，找出系统的极限承受能力	确定系统的崩溃点、恢复能力与最大并发数	内存泄漏、连接池耗尽、OOM、死锁
稳定性测试	在固定负载下长时间运行（通常 8~72 小时），观察系统是否存在渐进式劣化	验证系统在持续运行中的资源回收、内存增长与性能衰减情况	内存泄漏、文件句柄泄漏、GC 频繁、磁盘 I/O 积压
容量测试	通过逐步增加负载，确定系统在满足性能阈值前提下的最大处理能力	为容量规划、弹性伸缩与资源预算提供数据依据	扩容阈值不准确、资源浪费、过度规划

实践提示：在 Prometheus 采集作业平台中，负载测试通常模拟 1000~5000 个 target 的并发采集；压力测试则从 5000 个 target 起步，逐步增加至采集器崩溃或 Prometheus 内存溢出；稳定性测试建议至少运行 24 小时，并记录每小时的指标变化趋势。

2.2 四种测试类型的区别与联系

四种测试类型并非相互独立，而是构成一个完整的性能评估体系。下图展示了它们之间的逻辑关系与执行顺序。

2.3 关键区别维度对比

对比维度	负载测试	压力测试	稳定性测试	容量测试
负载模式	阶梯式递增至目标值	持续递增直至系统失效	固定负载（通常为 70%~80% 峰值）	阶梯式递增，记录每个阶梯的性能数据
持续时间	短（10~30 分钟）	中（30~120 分钟）	长（8~72 小时）	中（1~4 小时）
通过标准	响应时间 ≤ SLA，错误率 = 0	记录崩溃点与恢复时间	性能指标波动 ≤ 5%，无内存泄漏	在满足 SLA 前提下的最大吞吐量
Prometheus 场景	模拟 2000 target 采集	从 5000 target 加压至采集失败	3000 target 持续运行 24h	找出单实例最大 target 数

2.4 四种测试在 Prometheus 采集作业中的典型应用

负载测试：验证 Prometheus 在预期采集规模（如 2000 个 target，每 15s 采集一次）下，CPU 使用率是否低于 80%，内存增长是否平稳，查询响应时间是否在 1s 以内。
压力测试：逐步增加 target 数量至 8000、10000、12000，观察 Prometheus 何时出现 OOM 或采集超时，记录崩溃时的内存与 CPU 阈值。
稳定性测试：在 3000 target 的固定负载下运行 24 小时，每 30 分钟记录一次 prometheus_tsdb_head_series、process_resident_memory_bytes 等指标，检查是否存在持续增长趋势。
容量测试：以 500 target 为步长递增，记录每个阶梯下的 P99 查询延迟与采集成功率，确定满足“P99 延迟 ≤ 2s”条件下的最大 target 数。

  关键结论：四种测试类型构成完整的性能评估闭环。负载测试验证“能否跑”，压力测试找出“何时崩”，稳定性测试确认“跑多久”，容量测试回答“跑多少”。在 Prometheus 采集作业平台中，建议按“负载 → 压力 → 稳定性 → 容量”的顺序依次执行，每次测试的结果作为下一次测试的输入参数。

2.5 常见误区与避坑指南

误区	正确做法
将压力测试等同于负载测试	压力测试必须加压至系统失效，负载测试只需验证目标负载
稳定性测试时间不足 4 小时	Prometheus 内存泄漏通常需要 6~12 小时才能显现，建议至少 24 小时
容量测试只测一个点	容量测试需要多个阶梯数据点，才能拟合出性能拐点曲线
忽略测试间的依赖关系	先做负载测试确定基线，再做压力测试找极限，稳定性测试用基线负载，容量测试综合所有数据

注意：在 Prometheus 采集作业平台中，稳定性测试最容易暴露问题。许多团队只做负载测试就上线，结果在运行 12 小时后出现内存持续增长导致 OOM。务必在稳定性测试中监控 go_memstats_heap_inuse_bytes 和 prometheus_tsdb_head_chunks 的长期趋势。