JMeter配置2小时测试计划实现总160项、每小时最高80项创建时程序卡死的解决方法

• 测试目标：验证应用item创建全流程性能，单条完整创建流程包含500+请求，所有请求统一嵌套在事务控制器结构下组织
• 预期运行指标：总压测时长2小时，累计完成160个item创建，峰值创建速率为80个/小时，全程保持5个并发线程运行，通过随机CSV数据集为每个创建流程分配随机的创建者身份
• 现有实现：采用到达线程组实现流量配置，按照总item数折算设置固定到达率1.3个/分钟（折算逻辑：160个item / 120分钟）
• 现存异常：按当前配置运行时，JMeter客户端无响应卡死

核心问题根因 #

问题本质是没有匹配单条流程的实际处理时长与到达间隔的关系。到达线程组不会等上一个任务执行完成才发送下一个请求，它会严格按照设定速率往执行队列里塞入任务。单条创建流程包含500+请求，实际端到端处理时长通常远高于常规接口测试的单请求耗时，当处理时长大于设置的到达间隔时，未执行的任务会在JMeter客户端侧无限排队，持续占用内存，最终触发无响应卡死。当前配置的平均到达间隔约为46秒/条，只要单条创建流程的实际处理时长超过46秒，就会必然出现任务堆积。

具体调整动作 #

• 给到达线程组添加上限约束：设置最大待执行任务队列长度为5，与计划的并发数匹配。队列满后新的到达请求进入等待状态，从机制上杜绝无限制的任务堆积
• 修正流量模型配置：放弃全时段固定1.3个/分钟的平均速率配置，改用阶梯式速率匹配目标：前1小时以0.67个/分钟（40个/小时）的速率发送请求，后1小时爬坡到1.33个/分钟（80个/小时）的峰值速率，累计总请求数刚好为160个，完全匹配2小时总时长、峰值80个/小时的指标要求，同时避免启动初期就满速率导致的队列堆积
• 优化大事务结构的资源占用：
  • 给嵌套所有请求的事务控制器开启忽略子取样器结果配置，仅保留事务整体的统计结果，大幅降低结果存储的内存占用
  • 关闭所有非轻量型监听器，仅保留聚合报告这类仅做统计计算的组件，移除所有会实时渲染请求、响应内容的模块
  • 调整JMeter启动的JVM参数，将-Xmx堆内存上限设置为客户端物理内存的50%以上，避免默认的低堆内存配置无法承载大流程的取样结果
• 做线程数与速率的匹配校验：按照峰值80个/小时计算，5个线程的配置下，单条流程允许的最长处理时长为225秒（5个线程 * 3600秒 / 80个item），只要实际单流程处理时长不超过该值，就不会出现线程饱和堵队列的问题。如果单流程实际时长超过该阈值，可适当上调并发线程数，或下调峰值速率，保证任务队列长度始终在内存可承载范围内。

内容的提问来源于stack exchange，提问作者FarFarAway