几个小时后JMETER非常慢

时间:2017-02-22 07:12:16

标签: multithreading jmeter httprequest

我正在使用JMeter 3.1.1来运行负载测试。我的测试计划是40 threads,每个线程执行6 HTTP Requests。它在前几个小时运行正常,延迟大约为20ms。    几个小时后,延迟增长到500ms。我验证服务器处理正常。另外,我的测试计划中没有“监听器”,我在NonUI模式下运行它。    此外,似乎线程组一次只执行一个线程。因为我看到线程组每秒几乎没有执行一两个请求。

我真的很无能为力。任何帮助将不胜感激。

顺便说一句,内存和CPU消耗是正常的。

关于我的TestPlan

Total Thread Groups:4

1. Setup Thread Group
2. Load test thread group with 40 threads
   (Action To be taken after error :Continue
    Ramp-Up period: 0
    Number of Threads: 40
    Loop Count: Forever)

2.1 Counter  
2.2 Random Variable  
2.3 User Defined Variables  
2.4 If Condition = true  
    - 2.4.1 HTTP Request1  
    - 2.4.2 HTTP Request2  
    - 2.4.2 Loop for 5 times  
        -- 2.4.2.1 HTTP Request1  
        -- 2.4.2.2 HTTP Request2  

3. Introspection thread group with 1 thread
4. Tear Down thread group

如果需要更多详细信息,请告诉我

另一个观察是: 服务器有TIME_WAITs:4418(我检查HTTP请求的'使用保持活动'选项。,仍然有这么多的TIME_WAITs)

最新观察(感谢您的宝贵意见)

实际上,记忆必须是一个问题。我已经这样做了。,

-Xms512m -Xmx2048m -XX:NewSize = 512m -XX:MaxNewSize = 2048m

但我真的很想知道为什么JVM不会达到512 MB。所以我尝试了两个Xms和Xmx各2g。现在它的运行时间更长。然而,它的表现仍在放缓。可能是我的Beanshell Post处理器占用了所有内存。我真的很想知道他们为什么不释放记忆。如果你看到。,每小时表现如何降低。
小时#Requests发送
---- --------------
第1小时:1471917 第2小时:1084182(此时所有2g堆都用完了)
第3小时:705471
第4小时:442912
第5小时:255826
第6小时:136292

我读到Beanshell占用内存,但我别无选择,只能使用它,因为我必须在采样器中使用第三方jar来进行少量java调用。我不确定我是否可以使用JSR223(Groovy)或任何其他性能更好的采样器(前/后处理器)来做同样的事情

3 个答案:

答案 0 :(得分:0)

1)您是否使用标准脚本(jmeter / jmeter.bat)运行JMeter?

然后请注意,其中JVM堆的默认大小上限为512M。考虑增加它,至少在最大值结束时(平均值,更改默认值-Xmx512m)。

接下来要考虑的是-XX:NewSize = 128m -XX:MaxNewSize = 128m默认值。

以下是Oracle的建议:

  

在吞吐量较大的环境中,您应该考虑使用它   增加JVM年轻代的大小的选项。默认情况下,   年轻一代非常小,高吞吐量的情况可以   导致大量生成的垃圾。这垃圾   反过来,集合会导致JVM无意中被提升   短命的物体进入老一代。

所以尝试使用这些参数,这可能会有所帮助。

P.S。您是不是偶然在AWS EC2实例上运行它?如果是 - 实例类型是什么?

答案 1 :(得分:0)

你已经看到了我做过的堆设置。这里是Jmeter的内存和CPU利用率。我现在运行100个线程。我应该在测试计划中做些什么来降低CPU利用率。每4个HTTP请求后我有100ms的睡眠时间。

PID用户PR NI VIRT RES SHR S%CPU%MEM TIME + COMMAND
11850 xxx 20 0 7776m 2.1g 4744 S 678.2 27.4 6421:50 java

%CPU:678.2(波动率在99% - 700%之间)
MEM:2.1g(Xmx = 2g)

答案 2 :(得分:0)

感谢所有人,他们都试图帮助我 但是,我可以解决这个问题 罪魁祸首是:如果是Controller,它正在评估每个线程的每次迭代的条件。听起来很正常不是吗?问题是,条件是评估是基于JavaScript的。因此,所有线程都在使用CPU和内存来调用JavaScript   现在我得到了对服务器的一致请求,JMeter在100个线程的内存中也几乎稳定了1.9g内存   我发布这个以防万一任何人都可以受益而不浪费日夜搞清楚问题:)