0

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%。

4

1 回答 1

1

您应该在所有节点上运行相同的 JMeter 版本。如果这不能解决问题,请使用 jconsole 监控您的 JMeter 实例资源利用率。

于 2015-10-28T15:52:06.707 回答