JMeter中hold load含义、load与thread区别及请求数不达预期问题咨询

配置遗漏排查方向 #

• 检查步进线程组的测试总时长是否足够。如果你设置的Ramp Up步进总时长+保持负载时长过短，200线程还没全部启动完成、或者单线程还没跑完预设的迭代次数测试就提前终止，就会出现总请求数不达标的情况。另外确认单线程的迭代次数没有被设为固定1次，且没有勾选调度器后设置的测试结束时间早于所有线程执行完成的时间。
• 检查采样器的超时配置。如果HTTP等采样器没有设置合理的连接、响应超时，大量请求会因为阻塞占用线程资源，后续启动的线程无法正常发出请求，也会导致总请求数偏低。
• 排查JMeter自身性能瓶颈。200线程属于中等规模并发，如果你用GUI模式运行测试，或者测试机的CPU、内存、出口带宽占满，JMeter本身无法承载这么多并发线程，就会出现请求丢失的情况，建议切换为非GUI模式运行，同时调整jmeter.bat/jmeter.sh中的HEAP参数，提升JMeter的可用堆内存。

JMeter中load（负载）与thread（线程）的区别 #

• 线程是JMeter执行测试的最小独立单元，每个线程会独立执行你编排的测试逻辑，和其他线程的执行过程互不干扰，是JMeter实现并发的技术手段。
• 负载是指向被测服务端施加的压力总和，通常用并发请求数、每秒请求数（QPS/RPS）、响应时间、错误率这类业务指标衡量。线程数不等于负载：同样100线程，如果每个线程每次请求后等待100毫秒，和等待1秒，最终给服务端施加的负载差异可达10倍。

关于holding the loads的相关疑问 #

• holding the loads即保持负载阶段，这个阶段已经完成了所有目标线程的启动，JMeter会持续按照配置的逻辑向服务端发送请求，是你收集稳定性能数据的核心阶段。
• 保持负载的时长估算没有固定公式，核心取决于你的测试目标：
  • 如果是峰值性能测试，只要负载稳定运行10~15分钟，拿到稳定的TPS、响应时间、错误率数据即可，不需要过长时间。
  • 如果是稳定性测试，用于排查内存泄漏、连接泄漏等长时间运行才会暴露的问题，通常需要将时长设置为数小时甚至数天。
• 保持负载的时长需要结合业务场景评估，比如大促场景峰值需要持续2小时，那对应的压测保持负载时长至少要覆盖2小时以上。时长和线程数没有直接绑定关系，不管线程数是20还是200，都只需要匹配你的测试目标即可。

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