JMeter相同线程组配置两次运行聚合监听器结果不一致原因

JMeter压测结果不存在100%可复现性，即使所有线程组、采样器配置完全一致，两次运行出现错误率差异是非常常见的情况。压测是压测端、被测系统、网络链路多方参与的动态过程，任意环节的状态波动都会影响最终结果，常见原因可以分为三类：

被测系统侧状态差异 #

• 测试数据污染：第一次压测产生的业务数据没有清理，第二次运行时重复提交带唯一约束的参数（比如重复手机号注册、重复订单号提交），会直接触发业务报错；如果用了需要提前预置的测试数据（比如有效用户token、有效商品ID），第一次运行消耗完有效数据后，第二次运行会调用失效数据触发错误。
• 服务残留状态影响：第一次压测过程中如果打满了服务的数据库连接池、HTTP连接池，或者触发了内存泄漏、线程阻塞，压测结束后资源没有及时回收，第二次运行时服务本身已经处于亚健康状态，会出现大量超时、服务不可用错误。反过来如果第一次运行是服务冷启动状态，JIT编译未完成、本地缓存/分布式缓存未加载热点数据，第一次运行的响应时间会偏高，但如果第二次运行时服务刚好触发了GC、限流阈值触发、定时任务抢占资源，也会出现偶发错误。
• 依赖链路波动：被测服务依赖的数据库、缓存、下游第三方接口、消息队列的状态不是恒定的，第二次运行时刚好碰到数据库慢查询、下游接口限流、缓存击穿等情况，和JMeter配置无关，也会产生错误。

JMeter压测端状态差异 #

• 压测端资源不足：第一次运行结束后如果没有清空监听器缓存的结果数据，JMeter JVM堆内存会被历史结果占用，第二次运行时可能出现GC overhead、甚至OOM，导致请求无法正常发起，出现连接超时、请求发送失败的错误。如果压测机在第二次运行时刚好跑了其他占资源的进程（比如杀毒扫描、文件下载、系统自动更新），抢占了CPU、内存、带宽资源，也会导致JMeter请求发生产生延迟、堆积，触发超时错误。
• 组件配置的状态残留：如果你启用了HTTP缓存管理器、Cookie管理器，第一次运行时缓存、Cookie存储的失效条目没有清空，第二次运行会直接使用失效缓存/过期Cookie，触发请求错误。如果用CSV做参数化，没有正确配置Recycle on EOF和Stop thread on EOF选项，第一次运行把CSV数据读完后，第二次运行会取到空值或者非法参数，触发业务错误。

网络环境波动 #

压测机和被测服务之间的网络不是恒定可靠的，第二次运行时如果刚好碰到网络丢包、交换机流量高峰、带宽占满，会出现请求超时、连接重置类的错误，这类错误和两端配置都没有关系，属于公共网络的正常波动。

排查建议 #

不要只盯着聚合报告的错误率数字，第一步先去查看结果树组件里看错误请求的具体响应：

• 如果是Connection refused、Socket timeout、Connection reset类错误，优先排查网络连通性、压测机/被测服务的资源占用、服务是否存活
• 如果是返回4xx、5xx状态码的业务错误，优先核对测试参数是否有效、测试数据是否被污染、被测服务的业务日志有没有具体报错
• 每次压测前保证基准状态一致：重启JMeter清空历史结果、重置被测服务的测试数据（清理数据库压测记录、清空缓存）、确认所有依赖服务状态正常，再启动压测，能最大程度降低结果的随机波动。

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