下面是JMeter负载测试场景:
500 VU负载(分布在50个Docker示例上,每个示例10 VU)
我正在使用bzm -并发线程组,其中:
Target Concurrency: 10
Ramp up Time: 300 Sec
Ramp Up Steps Count: 12
Hold Target Rate Time ( sec ) : 150
我使用的是“一次性控制器”,共有5个样本x1c 0d1x
start: Thu May 12 15:02:22 UTC 2022
end: Thu May 12 15:12:49 UTC 2022
如果我们看一下日志的最后几行:
summary + 168 in 00:00:29 = 5.7/s Avg: 42368 Min: 268 Max: 102718 Err: 38 (22.62%) Active: 423 Started: 32453 Finished: 32122
summary = 1197 in 00:04:51 = 4.1/s Avg: 20447 Min: 8 Max: 102718 Err: 179 (14.95%)
summary + 171 in 00:00:31 = 5.6/s Avg: 52979 Min: 1817 Max: 108987 Err: 57 (33.33%) Active: 456 Started: 185979 Finished: 185615
summary = 1368 in 00:05:22 = 4.2/s Avg: 24513 Min: 8 Max: 108987 Err: 236 (17.25%)
summary + 165 in 00:00:31 = 5.2/s Avg: 47737 Min: 2400 Max: 135806 Err: 92 (55.76%) Active: 469 Started: 465197 Finished: 464820
summary = 1533 in 00:05:53 = 4.3/s Avg: 27013 Min: 8 Max: 135806 Err: 328 (21.40%)
summary + 226 in 00:00:28 = 8.1/s Avg: 45517 Min: 2391 Max: 138464 Err: 136 (60.18%) Active: 460 Started: 781788 Finished: 781420
summary = 1759 in 00:06:21 = 4.6/s Avg: 29390 Min: 8 Max: 138464 Err: 464 (26.38%)
summary + 213 in 00:00:31 = 7.0/s Avg: 41327 Min: 172 Max: 169472 Err: 121 (56.81%) Active: 452 Started: 1194172 Finished: 1193812
summary = 1972 in 00:06:52 = 4.8/s Avg: 30680 Min: 8 Max: 169472 Err: 585 (29.67%)
summary + 247 in 00:00:29 = 8.4/s Avg: 46833 Min: 305 Max: 189829 Err: 133 (53.85%) Active: 455 Started: 1625193 Finished: 1624830
summary = 2219 in 00:07:21 = 5.0/s Avg: 32478 Min: 8 Max: 189829 Err: 718 (32.36%)
summary + 179 in 00:00:30 = 5.9/s Avg: 49431 Min: 6934 Max: 186370 Err: 68 (37.99%) Active: 389 Started: 2079677 Finished: 2079380
summary = 2398 in 00:07:52 = 5.1/s Avg: 33743 Min: 8 Max: 189829 Err: 786 (32.78%)
summary + 206 in 00:00:31 = 6.7/s Avg: 60255 Min: 35 Max: 204533 Err: 89 (43.20%) Active: 247 Started: 2407457 Finished: 2407302
summary = 2604 in 00:08:22 = 5.2/s Avg: 35841 Min: 8 Max: 204533 Err: 875 (33.60%)
summary + 190 in 00:00:29 = 6.5/s Avg: 52622 Min: 326 Max: 261898 Err: 95 (50.00%) Active: 136 Started: 2502691 Finished: 2502647
summary = 2794 in 00:08:52 = 5.3/s Avg: 36982 Min: 8 Max: 261898 Err: 970 (34.72%)
summary + 282 in 00:00:29 = 9.6/s Avg: 49788 Min: 58 Max: 195675 Err: 140 (49.65%) Active: 14 Started: 2502691 Finished: 2502769
summary = 3076 in 00:09:21 = 5.5/s Avg: 38156 Min: 8 Max: 261898 Err: 1110 (36.09%)
summary + 50 in 00:00:30 = 1.7/s Avg: 29200 Min: 176 Max: 120778 Err: 17 (34.00%) Active: 3 Started: 2502691 Finished: 2502780
summary = 3126 in 00:09:51 = 5.3/s Avg: 38013 Min: 8 Max: 261898 Err: 1127 (36.05%)
summary + 16 in 00:00:12 = 1.3/s Avg: 17752 Min: 236 Max: 37998 Err: 6 (37.50%) Active: 0 Started: 2502691 Finished: 2502783
summary = 3142 in 00:10:03 = 5.2/s Avg: 37909 Min: 8 Max: 261898 Err: 1133 (36.06%)
Tidying up remote @ Thu May 12 15:12:42 GMT 2022 (1652368362418)
... end of run
++ date
+ echo 'END Running Jmeter on Thu May 12 15:12:49 UTC 2022'
10分钟运行500个虚拟线程(用户)
问:那么,如果负载为500个用户,我们为什么会有“Started:2502691英寸螺纹
我试着这样解释:您在“线程组”下定义了模拟真实的用户的线程(虚拟用户
JMeter启动线程,以尽可能快的速度执行采样器,并每秒生成一定数量的请求。
1.虚拟用户数
1.应用程序响应时间
查看:
summary + 16 in 00:00:12 = 1.3/s Avg: 17752 Min: 236 Max: 37998 Err: 6 (37.50%) Active: 0 Started: 2502691 Finished: 2502783
and
summary = 3142 in 00:10:03 = 5.2/s Avg: 37909 Min: 8 Max: 261898 Err: 1133 (36.06%)
这是否意味着,(最后一步:激发了3142个请求,整个测试花费了10分3秒,激发了每秒5.2个请求或每秒5.2个线程?
如果您有500个虚拟用户,并且应用程序响应时间为1秒,则您将拥有500 RPS
如果您有500个虚拟用户,并且应用程序响应时间为2秒,则您将拥有250 RPS
如果您有500个虚拟用户,并且应用程序响应时间为500毫秒,则您将拥有1000 RPS。
那么,“开始:2502691完成日期:2502783”数字代表什么?
这是否意味着目标系统可以处理10分钟内完成的2502783个线程或每秒4171个请求?但这与500 VU负载有何关系?
但是由于响应时间更长,所以这个数字应该更低,对吗?
1条答案
按热度按时间h7appiyu1#
我只能想到一个可能的原因:在“线程迭代次数限制”中有值
如果是这种情况--当一个线程开始执行线程组中的所有采样器时--它将被关闭,并启动一个新线程,以保持定义的并发性。
此外,Once Only Controller指示JMeter仅在线程组的第一次迭代期间运行其子线程,您应该使用它,例如,如果您希望登录一次,然后根据线程组计划运行其余采样器。
因此,我的期望是,如果您:
您应该只有500个已启动的虚拟用户,这些用户应该运行750秒。
实际的并发性由
Active
线程数表示,您可以通过使用Active Threads Over Time侦听器(可以使用JMeter Plugins Manager安装)打开.jtl results file来再次检查它