JMeter与k6容量压测脚本开发调试 - 第1节
1. 容量压测基础：定义、目标与价值
1.1 容量压测的定义
容量压测（Capacity Testing）是一种在预定义硬件、网络和软件配置下，通过逐步增加并发用户数或请求吞吐量，确定系统最大可承载容量并观察其性能拐点的测试方法。其核心目标是回答：“系统在满足 SLA（服务等级协议）的前提下，最多能支撑多少业务量？”
关键认知：容量压测不是简单地“压到系统崩溃”，而是在崩溃之前找到安全运行边界，为容量规划、弹性伸缩和成本控制提供数据依据。
1.2 容量压测的目标
- 确定最大容量阈值：找到系统在响应时间、错误率、吞吐量等关键指标达标时的最大并发用户数或 TPS（每秒事务数）。
- 识别性能拐点：定位资源利用率（CPU、内存、网络、磁盘 IO）从线性增长变为非线性增长的临界点。
- 验证弹性策略：在容器化或云原生架构中，验证自动扩缩容策略是否能在容量达到阈值前生效。
- 提供容量规划基线：为生产环境的资源预估、成本预算和扩容计划提供可量化的参考数据。
1.3 容量压测的价值
| 价值维度 | 具体体现 |
|---|---|
| 业务保障 | 避免大促、秒杀、突发事件期间因容量不足导致服务不可用，保障用户体验和营收。 |
| 成本优化 | 避免过度配置资源造成浪费，也避免配置不足导致性能瓶颈，实现资源与性能的平衡。 |
| 风险前置 | 在发布前发现数据库连接池、线程池、缓存、消息队列等组件的容量瓶颈，降低线上故障风险。 |
| 架构验证 | 验证分布式系统、微服务架构、数据库分库分表等设计是否满足预期的容量扩展能力。 |
实战经验：某电商平台在双十一前通过容量压测发现 Redis 集群在 80% 内存使用率时出现频繁的 key 逐出，导致缓存命中率从 95% 骤降至 60%。通过提前扩容和优化淘汰策略，避免了核心商品接口的雪崩。
2. 容量压测与负载测试、压力测试的区别
2.1 三种测试的核心差异
在性能测试领域，容量压测、负载测试和压力测试经常被混淆。三者的核心区别在于测试目的和负载模型的不同。下表从多个维度进行对比：
| 对比维度 | 负载测试 | 压力测试 | 容量压测 |
|---|---|---|---|
| 核心目的 | 验证系统在预期正常负载下的性能表现 | 找到系统崩溃点和恢复能力 | 确定系统最大可承载容量及性能拐点 |
| 负载模型 | 模拟典型业务场景的并发用户数或 TPS | 持续增加负载直至系统崩溃或出现严重错误 | 阶梯式增加负载，观察各阶梯的性能指标变化 |
| 关注指标 | 响应时间、吞吐量、错误率是否满足 SLA | 崩溃时的负载量、恢复时间、错误类型 | 性能拐点、资源利用率曲线、最大安全容量 |
| 测试终止条件 | 达到预设的目标负载且指标达标 | 系统崩溃或错误率超过阈值 | 找到性能拐点或达到资源瓶颈 |
| 典型应用场景 | 上线前的性能验收、回归测试 | 稳定性测试、灾难恢复测试 | 容量规划、弹性伸缩策略验证、大促备战 |
2.2 三种测试的关系示意图
下图展示了三种测试在负载递增过程中的位置和关系：
2.3 实战中的选择策略
在实际项目中，三种测试通常按以下顺序组合执行：
- 先做负载测试：验证系统在预期峰值负载（如 1000 并发）下是否满足响应时间 < 200ms、错误率 < 0.1% 的 SLA。
- 再做容量压测：从 500 并发开始，每 5 分钟增加 200 并发，观察 CPU 使用率、内存、TPS 的变化曲线，找到性能拐点。
- 最后做压力测试：在容量压测找到的拐点基础上，继续增加 30%~50% 的负载，观察系统是否优雅降级、能否自动恢复。
常见误区：很多团队只做负载测试，认为“系统能跑起来就行”。这会导致线上流量突增时，系统在毫无预警的情况下直接崩溃，因为没有提前知道容量边界在哪里。容量压测是连接“正常负载”和“极限负载”之间的关键桥梁。
2.4 三种测试的负载模型对比
在 JMeter 和 k6 中，三种测试的脚本编排方式有明显差异：
| 测试类型 | JMeter 线程组配置 | k6 脚本模式 |
|---|---|---|
| 负载测试 | 固定线程数（如 100），持续运行 10 分钟 | options.vus = 100; options.duration = '10m'; |
| 容量压测 | 阶梯线程组（Stepping Thread Group），每 2 分钟增加 50 线程 | ramping-arrival-rate 执行器，每阶段增加 50 RPS |
| 压力测试 | 持续增加线程数，直到错误率 > 10% 或响应时间 > 5s | thresholds 设置错误率阈值，触发后自动停止 |