场景设计篇：并发场景、阶梯加压场景、混合场景、稳定性场景的设计方法

场景设计，说白了就是回答一个问题：你到底想测什么？

我见过太多团队，上来就开1000个线程跑个接口，然后盯着TPS看半天。嗯，这其实叫「瞎跑」，不叫场景设计。真正的场景设计，你得先想清楚业务逻辑，再决定用什么模型去压。

这一章，我带你把这四种核心场景掰开揉碎。每个场景都有它的脾气，也有它的坑。

一、并发场景：最基础，也最容易翻车

并发场景，很多人以为就是「同时发起N个请求」。其实没那么简单。你想想看，真正的并发，是多个用户在同一时间窗口内对系统发起操作，而不是在同一毫秒内发请求。

核心目标：验证系统在指定并发用户数下的处理能力，以及是否存在资源竞争、死锁等问题。

设计方法

  1. 确定并发数：根据业务峰值预估。比如双11的峰值QPS是10000，平均响应时间200ms，那并发数 ≈ 10000 × 0.2 = 2000。
  2. 选择接口：一般选核心交易链路，比如登录、下单、支付。别把查询接口当并发场景压，那没意义。
  3. 设置集合点：用JMeter的Synchronizing Timer，让所有线程在同一时刻发起请求。我习惯设置超时时间，防止某个线程卡死导致整个场景挂掉。
我的经验：有一次压一个支付接口，并发数从100涨到200，TPS反而下降了。查了半天，发现是数据库连接池太小，线程都在等连接。嗯，这就是并发场景的价值——暴露资源瓶颈。 
// JMeter 集合点配置示例
// 在请求前添加 Synchronizing Timer
// Number of Simulated Users to Group: 0 (表示所有线程)
// Timeout in milliseconds: 5000 (5秒超时)

二、阶梯加压场景：摸清系统的「天花板」

阶梯加压，说白了就是慢慢加人，看系统什么时候扛不住。我个人特别喜欢这个场景，因为它能告诉你系统的拐点在哪里。

为什么会这样？因为系统不是线性的。你加10个用户，TPS涨100；再加10个，TPS可能只涨50；再加10个，TPS反而跌了。这个「跌」的点，就是系统的极限。

设计方法

  • 阶梯步长：一般每步增加10%-20%的并发数。比如从10开始，每30秒增加10个用户，直到500。
  • 持续时间：每步持续30-60秒，让系统有足够时间「反应」。我见过有人每步只跑5秒，那数据根本不准。
  • 监控指标：重点关注TPS、响应时间、错误率、CPU、内存。一旦出现拐点，立刻记录。
避坑指南：我曾经用阶梯加压压一个微服务，发现TPS在并发200时突然下降。排查后发现是线程池满了，请求开始排队。但奇怪的是，CPU才用了40%。这说明系统瓶颈不在CPU，而在线程池配置。嗯，这就是阶梯加压的价值——帮你定位瓶颈类型。 
// JMeter 阶梯加压配置（使用 Ultimate Thread Group）
// 参数示例：
// Start Threads Count: 10
// Initial Delay, sec: 0
// Startup Time, sec: 5
// Hold Load For, sec: 30
// Shutdown Time, sec: 5

// 多阶梯配置：
// 阶梯1: 10线程, 保持30秒
// 阶梯2: 20线程, 保持30秒
// 阶梯3: 40线程, 保持30秒
// 阶梯4: 80线程, 保持30秒
// ... 以此类推

三、混合场景：最贴近真实业务

混合场景，说白了就是模拟真实用户的行为。真实用户不会只点一个按钮，他们会登录、浏览、下单、支付……你得把这些操作按比例混在一起。

我刚开始做性能测试时，就犯过这个错——只压下单接口，结果上线后系统崩了。为什么？因为真实用户有80%在浏览商品，只有20%在下单。我只压下单，把浏览的负载完全忽略了。

设计方法

  • 业务比例：根据生产日志统计各接口的调用比例。比如登录:浏览:下单:支付 = 10:60:20:10。
  • 线程分配：按比例分配线程数。比如总线程100，登录10个，浏览60个，下单20个，支付10个。
  • 思考时间：加随机思考时间，模拟用户操作间隔。我一般用高斯随机分布，均值3秒，标准差1秒。
核心原则：混合场景不是简单地把接口拼在一起，而是要模拟用户的行为路径。比如用户必须先登录，才能下单，才能支付。这些依赖关系必须处理好。 
// JMeter 混合场景配置示例
// 使用 Throughput Controller 控制比例

// 登录接口 - 10%
// 浏览商品 - 60%
// 加入购物车 - 5%
// 下单 - 20%
// 支付 - 5%

// 思考时间配置（高斯随机）
// 均值: 3000ms
// 标准差: 1000ms

四、稳定性场景：压它个通宵

稳定性场景，说白了就是长时间压测，看系统会不会「慢慢变慢」或者「突然挂掉」。我见过太多系统，跑10分钟没问题，跑2小时就内存泄漏了。

为什么会这样？因为有些问题需要时间才能暴露。比如内存泄漏、连接池耗尽、磁盘写满、日志文件过大……这些问题在短时间压测里根本看不出来。

设计方法

  • 持续时间：至少4小时，建议8-12小时。我习惯压24小时，因为有些内存泄漏需要一整天才能暴露。
  • 并发数：取系统峰值的70%-80%。别压满，因为稳定性场景的目的是验证系统能否「持续」运行，而不是「极限」运行。
  • 监控指标：重点关注内存趋势、GC频率、连接池使用率、磁盘IO。如果内存曲线持续上升，那大概率有泄漏。
避坑指南：我曾经压一个Java应用，跑了6小时一切正常。结果第7小时，TPS突然掉到0。查日志发现是Full GC把应用停了30秒。嗯，这就是稳定性场景的价值——暴露那些「慢刀子割肉」的问题。 
// 稳定性场景监控指标示例
// 重点关注以下指标的「趋势」而非「瞬时值」

// 1. 内存使用率 - 是否持续上升
// 2. GC次数和耗时 - 是否越来越频繁
// 3. 线程数 - 是否持续增加
// 4. 连接池使用率 - 是否接近上限
// 5. 磁盘空间 - 日志是否写满
// 6. 响应时间 - 是否逐渐变慢

四种场景的关系

这四种场景不是孤立的，它们是一个完整的压测体系。我个人习惯这样组织：

  1. 先用并发场景快速验证核心接口
  2. 再用阶梯加压摸清系统天花板
  3. 然后用混合场景模拟真实业务
  4. 最后用稳定性场景验证长期运行

你想想看，如果跳过阶梯加压直接跑混合场景，你连系统的拐点都不知道，怎么判断混合场景的结果是否合理？

我的建议：每次压测前，先画一张场景设计图。把你要压的接口、并发数、持续时间、监控指标都写清楚。别嫌麻烦，这张图能帮你省掉80%的排查时间。
吞吐压测场景设计体系 场景设计 并发场景 阶梯加压场景 混合场景 稳定性场景 集合点控制 资源竞争检测 步长递增 拐点定位 业务比例 思考时间 长时间运行 内存泄漏检测 四种场景相互配合，构成完整的压测体系

好了，这四种场景的设计方法就讲完了。记住，场景设计不是死板的模板，而是要根据你的业务特点灵活调整。你想想看，一个电商系统和一个支付系统的场景设计，能一样吗？

想要更多资料，联系可可

← 上一章 📖 返回目录 下一章 →