[英]JMeter frequency peaks when using ultimate thread group
I use Ultimate Thread Group for performance testing in JMeter.我在 JMeter 中使用 Ultimate Thread Group 进行性能测试。 In combination with a timer I want to scale the number of users/threads dynamically while each user has a constant throughput of eg 10 requests/sec.
结合计时器,我想动态扩展用户/线程的数量,同时每个用户都有一个恒定的吞吐量,例如 10 个请求/秒。
When the Ultimate Thread Group increases the number of users, the total request rate per second will have a high peak for a short time.当 Ultimate Thread Group 增加用户数时,每秒总请求率会在短时间内出现高峰。 After the peak, the request rate is as expected.
高峰过后,请求率符合预期。
For example, I get this trace: Start with 40 users, 10 requests per second for each user: 40 * 10 = 400 requests/second .例如,我得到以下跟踪:Start with 40 users, 10 requests per second for each user: 40 * 10 = 400 requests/second 。 Increase the number of users up to 60, I expect 60 * 10 = 600 requests/second , but I get a peak of more than 3959 requests/second at the beginning.
将用户数增加到 60 个,我预计60 * 10 = 600 个请求/秒,但一开始我的峰值超过3959 个请求/秒。
summary = 366401 in 00:15:16 = 400.0/s Avg: 1 Min: 0 Max: 1071 Err: 0 (0.00%)
summary + 12000 in 00:00:30 = 400.0/s Avg: 1 Min: 0 Max: 20 Err: 0 (0.00%) Active: 40 Started: 40 Finished: 0
summary = 378401 in 00:15:46 = 400.0/s Avg: 1 Min: 0 Max: 1071 Err: 0 (0.00%)
summary + 12000 in 00:00:30 = 400.0/s Avg: 1 Min: 0 Max: 44 Err: 0 (0.00%) Active: 40 Started: 40 Finished: 0
summary = 390401 in 00:16:16 = 400.0/s Avg: 1 Min: 0 Max: 1071 Err: 0 (0.00%)
summary + 31784 in 00:00:30 = 1061.9/s Avg: 4 Min: 0 Max: 414 Err: 0 (0.00%) Active: 60 Started: 60 Finished: 0
summary = 422185 in 00:16:46 = 419.7/s Avg: 1 Min: 0 Max: 1071 Err: 0 (0.00%)
summary + 118770 in 00:00:30 = 3959.0/s Avg: 5 Min: 0 Max: 493 Err: 0 (0.00%) Active: 60 Started: 60 Finished: 0
summary = 540955 in 00:17:16 = 522.2/s Avg: 2 Min: 0 Max: 1071 Err: 0 (0.00%)
summary + 79419 in 00:00:30 = 2647.3/s Avg: 10 Min: 0 Max: 1435 Err: 0 (0.00%) Active: 60 Started: 60 Finished: 0
summary = 620374 in 00:17:46 = 582.0/s Avg: 3 Min: 0 Max: 1435 Err: 0 (0.00%)
summary + 37227 in 00:00:30 = 1238.1/s Avg: 6 Min: 0 Max: 1354 Err: 0 (0.00%) Active: 60 Started: 60 Finished: 0
summary = 657601 in 00:18:16 = 600.0/s Avg: 3 Min: 0 Max: 1435 Err: 0 (0.00%)
summary + 18000 in 00:00:30 = 600.3/s Avg: 2 Min: 0 Max: 219 Err: 0 (0.00%) Active: 60 Started: 60 Finished: 0
summary = 675601 in 00:18:46 = 600.0/s Avg: 3 Min: 0 Max: 1435 Err: 0 (0.00%)
summary + 18000 in 00:00:30 = 599.9/s Avg: 1 Min: 0 Max: 46 Err: 0 (0.00%) Active: 60 Started: 60 Finished: 0
visualized it looks like this:可视化它看起来像这样:
Is there a way to avoid this peak?有没有办法避免这个高峰? (I also get this peak if I increase the number of users from 60 to 80.80 to 100, ...)
(如果我将用户数量从 60 增加到 80.80 到 100,我也会达到这个峰值,...)
In combination with which "timer"?结合哪个“计时器”?
I think you're using the wrong timer and the wrong thread group for your scenario, consider moving to Concurrency Thread Group and Throughput Shaping Timer , you can connect them using feedback function so the timer will be the only place which will drive the load pattern.我认为您为您的场景使用了错误的计时器和错误的线程组,考虑转移到并发线程组和吞吐量整形计时器,您可以使用反馈 function连接它们,因此计时器将是驱动负载模式的唯一地方.
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.