JMeter机器的版本：2.13 r13365067,2.11.20140918 | Java：OpenJDK 1.7.0_79 | 操作系统：Debian 8.1
我遇到的问题是，某些HTTP请求似乎在负载注入器上处理的时间太长，而且还没有加载。
来自20个vU的测试结果文件的示例（带缓存，较弱的负载注入器，JMeter v2.11）和40vU（没有缓存，更高规格的负载注入器，JMeter v2.13）：< / p>
<time_stamp>,3257,<request_name>,200,<thread_name>,true,28537,20,20,437
<time_stamp>,5158,<request_name>,304,<thread_name>,true,138,40,40,0
第一种情况下内存为75％，第二种情况下内存低于50％。在两个示例中，CPU似乎没有尖峰（以1秒间隔测量）并且最多达到20％。 检查了JVM的垃圾收集，看起来GC在请求时是否达到了极限（实际上在测试期间没有任何时候）。
我注意到了这种情况，我有缓存（通过缓存管理器使用＆＃34;使用缓存控制/过期标头...＆＃34;已选中），并且，如上面第二个示例中所示，获取不切实际的响应时间为5158毫秒。
这只发生在迭代期间的某些步骤和多个线程中，但不是全部。
似乎JMeter以某种方式处理结果的时间过长，但我无法确定我的负载注入器处于高负载状态，导致处理时间为几秒钟。
显然这会弄乱性能统计数据，所以我想知道这是怎么回事。
希望有人可以提供帮助。
编辑： @First示例：ResponseTime＆gt;＆gt;的情况Latecy＆gt; 0，发生在两台JMeter机器上（JMeter v2.11，JMeter v2.13）。
@Second示例：ResponseTime＆gt;＆gt;的案例在使用JMeter v2.13的计算机上，Latecy = 0仅在 上发生。
第二次编辑： 事实证明，我运行的JMeter版本（或在哪个节点上）并不重要。
正则表达式＆＃d;我的结果文件： 在相同的请求资源中，缓存（延迟= 0），使用标头检查，大约10％需要1秒或多秒。没有标题检查它是6％。
答案 0 :(得分：1)
您应该在所有节点上运行相同的JMeter版本。如果这不能解决问题，请使用jconsole监视JMeter实例资源利用率。