本文介绍了Jmeter吞吐量整形计时器发送更多所需的请求的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在将Jmeter 4.0与吞吐量整形计时器一起使用,并提到了我的配置,如下所示:

I am using Jmeter 4.0 with Throughput Shaping Timer and I have mentioned my configuration as follows:

bzm-并发线程组:

bzm - Concurrency Thread Group:

  • 目标并发1000
  • 启动时间:1
  • 升级步骤:1
  • 保留目标率:100分钟

jp @ gc-吞吐量整形计时器启动RPS:333 ||最终Rps:333 ||持续时间(秒):1200

jp@gc - Throughput Shaping TimerStart RPS: 333 || End Rps: 333 || Duration(sec): 1200

由于测试持续时间为1200秒,Rps为333/秒,因此通过测试的请求命中数应为(333 * 1200)=399600.但是实际的命中数在400000-410000请求范围内第二.

Since the test duration is mentioned as 1200 seconds and Rps is 333/sec so number of request hits through the test should be (333*1200) = 399600. But actual number of hits coming in range of 400000 - 410000 Requests per second.

如何限制吞吐量整形计时器以不发送额外的请求?

How can Throughput Shaping Timer be restricted to not send extra requests?

推荐答案

您的总测试持续时间isn't 1200 seconds.查看并发线程组配置,您的测试持续时间精确地为6001秒(1000个用户的启动时间为1秒,保持目标速率时间为6000秒).

Your Total test duration isn't 1200 seconds. Looking into your Concurrency Thread Group Configurations, your test duration is exactly 6001 seconds (Ramp up for 1000 user is 1 sec and the Hold Target Rate time is 6000 seconds).

要获得所需的RPS,必须遵循以下公式来定义并发线程组中的线程数:

To get your desired RPS, You have to follow the below formula to define the number of threads in Concurrency Thread Groups:

如果您的响应时间为1 second,则333 Threads足以实现此RPS.我猜在这种情况下,您使用了更多线程.

If your response time is 1 second, then 333 Threads are enough to achieve this RPS. You have used more threads in this case I guess.

根据您给定的测试计划,它的工作方式就像1秒钟内有1000个用户处于活动状态,然后他们将尝试在1200秒内达到333 RPS,然后将保留1000个用户的剩余时间请求(6001-1220 = 4801秒),如您提到的1000个用户将保持负载100分钟.因此,您收到的请求超出了预期.

According to your given test plan, it is working like 1000 users are active in 1 second and then they will try to achieve 333 RPS for 1200 seconds and then they will maintain 1000 users requests for remaining time (6001-1220=4801 seconds) as you mentioned 1000 users will hold the load for 100 mins. For this reason, you are getting extra requests than desired.

因此,在线程组中定义线程数并相应地增加时间,并正确同步测试持续时间(在这种情况下,保持加载时间可能是20分钟而不是100分钟).

So, Define number of threads and ramp up time accordingly in your Thread groups and also sync your test duration properly (in this case hold load time could be 20 mins not 100 mins).

这篇关于Jmeter吞吐量整形计时器发送更多所需的请求的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

08-07 09:07