JMeter分布式压测无法达到预期请求数问题求助

1. 线程组配置偏差 #

• 分布式模式下，Master设置的线程数是单台Slave的线程数，而非集群总线程数。按你的配置：单线程3个采样器，要每台Slave产出1000次请求，需设置循环次数为 1000 / (20*3) ≈ 17。检查线程组的“循环次数”是否正确设置，若用调度器，需确保持续时间足够覆盖所有线程完成循环。
• 若勾选了“延迟创建线程直到需要”，且测试持续时间过短，会导致部分线程未启动就终止，直接减少请求数。

2. Slave节点未全部在线 #

• 在Master的JMeter界面查看分布式测试面板，确认50台Slave是否全部显示为Connected。如果部分节点未连接，实际参与压测的Slave数量远少于50，总请求数自然打折扣。
• 查看Slave节点的jmeter-server.log，排查是否有连接失败、端口占用、内存不足等启动报错。

3. 测试时长或循环配置不合理 #

• 若使用调度器设置了“持续时间”，需计算单台Slave的QPS：目标请求数1000 / 持续时间(秒) = 所需QPS。如果Slave实际QPS达不到这个值，或持续时间太短，请求数就会不足。建议改为固定循环次数，确保每台Slave完成指定次数的请求。

4. 资源瓶颈限制 #

• Slave端资源耗尽：用top（Linux）或任务管理器（Windows）监控Slave的CPU、内存、网络负载。如果任何一项接近100%，线程会因资源不足无法正常执行。可以降低单台Slave的线程数，或优化采样器（比如移除冗余断言、缩短超时时间）。
• Master端资源瓶颈：Master需要接收所有Slave的测试结果，若内存或带宽不足，可能会主动终止部分Slave的测试。可修改jmeter.properties中的mode=Standard为mode=Stripped，减少Master接收的数据量。

5. 采样器逻辑异常 #

• 检查采样器是否嵌套了条件控制器（如If Controller），导致部分采样器未执行，实际单线程有效请求数不足3个。
• 查看jmeter.log中的错误日志，确认是否有请求超时、服务端限流等导致的请求失败。如果失败请求过多且未配置重试，总请求数会低于预期。

6. JMeter版本或配置不一致 #

• 确保Master和所有Slave的JMeter版本完全一致，版本不匹配会导致分布式命令执行异常，测试提前终止。
• 检查Slave的jmeter.properties，确认server_port未被占用，且remote_hosts指向正确的Master地址。

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