【问题标题】:JMeter stops sending HTTP Requests for specific threadsJMeter 停止为特定线程发送 HTTP 请求
【发布时间】:2014-09-12 13:51:09
【问题描述】:

我正在使用 JMeter 2.11。 jmeter.bat文件中定义了以下参数

设置 HEAP=-Xms512m -Xmx12144m 设置 NEW=-XX:NewSize=128m -XX:MaxNewSize=128m 设置 SURVIVOR=-XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=50% 设置 TENURING=-XX:MaxTenuringThreshold=2 设置 RMIGC=-Dsun.rmi.dgc.client.gcInterval=600000 -Dsun.rmi.dgc.server.gcInterval=600000 设置PERM=-XX:PermSize=64m -XX:MaxPermSize=64m

测试以批处理模式启动。 jmeter 结果以 XML 格式存储在 jtl 文件中。

我们制作了一个需要 while 语句的场景。 如果我们删除 while 语句,JMeter 可以同时处理 50 个用户。

如果我们添加 while 语句,大约 80% 的 JMeter 用户线程被正确执行(40 个用户正在执行该场景没有任何问题)。 20% 的 JMeter 用户线程在可变期间停止:有时 15 分钟,有时 40 分钟,有时一个小时,然后场景继续下一条语句(10 个用户正在启动请求,然后在 15 分钟内停止,然后重新启动)。

通过使用调试采样器跟踪活动,它通常会在几秒钟的计时器之前或之后停止。例如,它在 40 分钟内停止,40 分钟后,它再次发送 HTTP 请求(问题是我的 IIS 应用程序会话超时并且所有请求都失败)。 似乎我们添加的调试采样器越多,JMeter 越能正常工作。 没有日志...

我们尝试了以下方法:

  • 更改 JMeter.bat 设置

  • 升级JMeter版本

  • 增加计时器以减轻场景压力

没有任何作用。我们仍然有问题。因此,我想知道 JMeter 是否已达到其最大容量。 需要注意的是,注入器CPU在60%左右,内存还可以。

我担心的是50个用户太少了……我们需要处理1000个用户的测试,我们不能买20台机器来处理注射器。

如果有人对此问题有任何想法,我将不胜感激。

问候

西尔维

【问题讨论】:

标签: jmeter


【解决方案1】:

我认为您的问题更多地与您的服务器因负载而变慢有关,并且您没有在 Http Request 上设置超时这一事实意味着它们会等到您的服务器响应。

所以首先要做的是在HTTP Request Default element 中设置连接和响应超时。

接下来是检查您在负载测试时是否遵循最佳实践,请参阅:

最后关于你的 GC 调整,我建议你保持:

设置 HEAP=-Xms512m -Xmx12144m

设置PERM=-XX:PermSize=64m -XX:MaxPermSize=64m

作为一个总结,JMeter 将能够毫无问题地加载测试 1000 个用户,而您不需要 20 台机器来完成这个 :-)

【讨论】:

  • 您好,我在 HTTP 请求默认值上添加了有关连接超时和响应超时的参数化。我将 Connect 设置为 1000 并响应 2000,JMEter 向我发送了一个套接字错误:java.net.SocketTimeoutException: Read timed out at sun.reflect.GeneratedConstructorAccessor33.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source )
  • 所以这证实了我所说的,即它不是挂起的jmeter,它只是在等待来自服务器的响应,当你添加超时你说我只会等待2s,一个合理的等待应该是更高并且连接应该低于响应超时。无论如何现在调查服务器性能。
  • 你好,我仍然有这个问题,这似乎是由于 JMeter 端的堆栈溢出。您可以查看有关我的问题的其他信息。问候西尔维
【解决方案2】:

我使用 JMeter.bat 文件中设置的 ThreadStackSize=4096 进行了测试,但我仍然遇到问题(我的场景是以批处理模式启动的)。 发送以下请求:

**Sent at 19/09/2014 12:06:06**


<sample t="0" lt="0" ts="1411121166434" s="true" lb="------------------------Begin Loop Page de prop App   From Tree " rc="200" rm="OK" tn="Groupe d&apos;unitأ©s  APM 1-9" dt="text" by="923">

**sent at  19/09/2014 12:36:16**


<sample t="0" lt="0" ts="1411122975778" s="true" lb="----------Technology  " rc="200" rm="OK" tn="Groupe d&apos;unitأ©s  APM 1-9" dt="text" by="923">

如您所见,两个请求之间有 30 分钟的时间

匹配的JMeter View如下:

“Begin Loop Page de prop App From Tree”是一个调试采样器,它通过一个“If Create Scope”,它是一个“If 语句”,然后是一个“循环创建技术”,其中循环设置为 1,如图所示下面:

在调试采样器“Begin Loop Page de prop App From Tree”之后 30 分钟执行调试采样器“--------------技术”。

使用的定时器是Constant Timer。

应该注意的是,我在另一个使用高斯计时器的场景中遇到了同样的问题。计时器值取决于操作,但介于 2000 毫秒和 6000 毫秒之间。 在另一种情况下,如果我删除 while 语句,则该方案有效……不幸的是,我需要 while 语句。 在这种情况下,问题似乎来自设置为 1 的循环。

关于 VisualVM 工具,我刚刚看到垃圾收集器非常频繁地完成。我没有看到内存问题...但是我会在下一次测试中查看它。

希望对你有帮助

问候

西尔维

【讨论】:

    【解决方案3】:

    事实上,我在上面进行的连接超时设置为 1000 和响应超时设置为 2000 的测试是在单个线程(用户)上进行的。 所以套接字错误可能是由于连接超时参数太低...

    我更改了这些参数并将连接超时设置为 60 000(1 分钟)并将响应超时设置为 360 000(6 分钟,因为有时我们有不发送响应的请求,我们将它们限制为 5 分钟,这是非常罕见的,但这是阻止场景)。

    我从 JMeter.bat 文件中删除了这个:

    set NEW=-XX:NewSize=128m -XX:MaxNewSize=128m 
    set SURVIVOR=-XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=50% 
    set TENURING=-XX:MaxTenuringThreshold=2 
    set RMIGC=-Dsun.rmi.dgc.client.gcInterval=600000 -Dsun.rmi.dgc.server.gcInterval=600000 set PERM=-XX:PermSize=64m -XX:MaxPermSize=64m
    

    我以批处理模式播放我的场景,有 50 个用户。看来我们不再有被阻塞的线程了。不幸的是,我们的大多数用户都看到了以下情况:一个请求被播放,服务器以良好的延迟响应(不到一秒),下一个请求在一小时后播放,这给出了 500 HTTP 错误....

    示例:如果我们看一下 Group6 单元。以下是播放并写入JTL文件中

    <httpSample t="13" lt="13" ts="1410856270124" s="true" lb="/hopex/service.aspx?data=generationType-standard|generator-E98AEA3A4F717715" rc="200" rm="OK" tn="Groupe d'unités 1-6" dt="text" by="412">
      <java.net.URL>http://172.16.1.23/hopex/service.aspx?data=generationType-standard|generator-E98AEA3A4F717715</java.net.URL>
    </httpSample>
    
    **played at 16/09/2014 10:31:10**
    
    
    <httpSample t="0" lt="0" ts="1410856270138" s="true" lb="/hopex/statesessionprovider.aspx" rc="200" rm="OK" tn="Groupe d'unités 1-6" dt="text" by="238">
      <java.net.URL>http://172.16.1.23/hopex/statesessionprovider.aspx</java.net.URL>
    </httpSample>
    
    **played at 16/09/2014 10:31:10**
    
    
    
    <sample t="0" lt="0" ts="1410856274818" s="true" lb="Timer between steps" rc="200" rm="OK" tn="Groupe d'unités 1-6" dt="text" by="1478"/>
    
    **played at 16/09/2014 10:31:15**
    
    
    <httpSample t="3" lt="3" ts="1410860493293" s="false" lb="/Hopex/service.aspx?data=generationType-standard|generator-E98AEA3A4F717715" rc="500" rm="Internal Server Error" tn="Groupe d'unités 1-6" dt="text" by="298">
      <java.net.URL>http://172.16.1.23/Hopex/service.aspx?data=generationType-standard|generator-E98AEA3A4F717715</java.net.URL>
    </httpSample>
    
    **played at 16/09/2014 11:41:33**

    大多数时候,我们只是在计时器之后遇到问题。在这里,您可以看到最后一个请求比上一个请求播放了一个多小时(这是一个 JMeter 计时器)... 我们的应用程序日志显示最后一个请求从未发送到应用程序。 所以这意味着JMeter在发送请求之前暂停了一个多小时。 应该注意的是,如果我们从场景中删除 while 语句,它就可以工作。 还应注意,错误不适用于 while 语句附近。

    由于您认为服务器过载,因此我使用性能监视器注册了 Windows 指标。 测试期间的平均 CPU 似乎在 10% 左右(可能是因为大多数线程都停止了)。如果我看一下 10:31,CPU 不会超过 30%。

    如果我检查了内存消耗,当问题发生时有 20 GB 的 RAM 可用。

    所以,我认为服务器并没有超载...

    我从 JMeter 日志中检索此信息。似乎问题来自具有堆栈溢出的 JMeter。我不知道如何解决这个问题。我试图改变 JMeter.bat 参数,但我们有副作用。 这是 JMeter 日志的一部分:

    2014/09/16 10:30:49 WARN  - jmeter.control.GenericController: StackOverflowError detected 
    2014/09/16 10:30:49 WARN  - jmeter.control.GenericController: StackOverflowError detected 
    2014/09/16 10:30:49 WARN  - jmeter.control.GenericController: StackOverflowError detected 
    2014/09/16 10:30:51 WARN  - jmeter.control.GenericController: StackOverflowError detected 
    2014/09/16 10:31:00 INFO  - jmeter.reporters.Summariser: summary +    196 in    30s =    6.5/s Avg:   154 Min:     0 Max: 11347 Err:     0 (0.00%) Active: 50 Started: 50 Finished: 0 
    2014/09/16 10:31:00 INFO  - jmeter.reporters.Summariser: summary =   5974 in  1103s =    5.4/s Avg:   406 Min:     0 Max: 47864 Err:     0 (0.00%) 
    2014/09/16 10:31:01 WARN  - jmeter.control.GenericController: StackOverflowError detected 
    2014/09/16 10:31:32 INFO  - jmeter.reporters.Summariser: summary +    154 in    32s =    4.9/s Avg:    94 Min:     0 Max: 10982 Err:     0 (0.00%) Active: 50 Started: 50 Finished: 0 
    2014/09/16 10:31:32 INFO  - jmeter.reporters.Summariser: summary =   6128 in  1135s =    5.4/s Avg:   399 Min:     0 Max: 47864 Err:     0 (0.00%) 
    2014/09/16 10:31:37 WARN  - jmeter.control.GenericController: StackOverflowError detected 

    我从一个月以来一直在处理这个问题,但我不知道如何解决它...... 如果您有想法,我将不胜感激。

    问候

    西尔维

    【讨论】:

    • 你能给我们一张你的 JMeter 个人资料的照片,看看你使用了哪些元素(扩展视图)?还有你用什么样的定时器,你设置了多少等待?我也会尝试使用不同的 JRE 版本。 JMeter 邮件列表中有人描述了类似的问题,在这种情况下使用 ThreadStackSize=4096 解决了该问题。还可以尝试从您的个人资料中删除 while 循环。您也可以将VisualVM附加到jmeter,以检查内存消耗是否有任何异常。
    • 您好,我通过回答标签给您发送了回复,提前感谢您的回复。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2022-12-11
    相关资源
    最近更新 更多