JMeter 机器版本:2.13 r13365067、2.11.20140918 | Java:OpenJDK 1.7.0_79 | 操作系统:Debian 8.1
我遇到了一个问题,即某些 HTTP 请求似乎在负载注入器上处理的时间过长,而负载注入器并没有真正处于负载之下。
来自具有 20 个 vU(具有缓存,在较弱的负载注入器上,JMeter v2.11)和 40 个 vU(没有缓存,在更高规格的负载注入器上,JMeter v2.13)的测试结果文件的示例:
<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 也没有达到极限(实际上在测试期间没有任何时候)。
在启用缓存(通过缓存管理器并选中“使用缓存控制/过期标头...”)的情况下,我注意到了这一点,并且像上面的第二个示例一样,得到了 5158 毫秒的不切实际的响应时间。
这只发生在迭代期间的某些步骤和多个线程,但不是全部。
似乎 JMeter 以某种方式处理结果的时间过长,但我真的看不出我的负载注入器负载很重,导致处理时间为几秒钟。
显然,这弄乱了性能统计数据,所以我想知道这是怎么发生的。
希望有人可以提供帮助。
编辑:@First 示例:ResponseTime >> Latecy > 0 的情况发生在两台 JMeter 机器(JMeter v2.11、JMeter v2.13)上。
@第二个示例:ResponseTime >> Latecy = 0 的情况仅发生在使用 JMeter v2.13 的机器上。
第二次编辑:事实证明,我运行什么 JMeter 版本(或在哪个节点上)并不重要。
正则表达式我的结果文件:对于相同的请求资源,缓存(延迟 = 0),带有标头检查,大约 10% 需要 1 秒或多秒。如果没有标题检查,它是 6%。