Jmeter - 1000个并发用户不是同时创建的

我写了一个jmeter脚本，其中线程数为1000，加速时间为1，循环是永久的，持续时间是一个小时。Jmeter - 1000个并发用户不是同时创建的

当我运行这个脚本时，我看到jmeter开始创建线程，并且当我将循环设置为永远，所以非线程应该在持续时间结束之前完成。

但问题是，jmeter不能同时创建这些线程。我从摘要中添加了短日志细节。

完全在1分钟内创建了76个线程。在10分钟内共创建了264个线程。在59分钟内创建了590个线程。

然后它开始结束现有的线程，因为它已经是一个小时了，接下来开始创建其他510个线程。最后，它显示创建了1000个线程。

但实际上它必须同时创建它们，也许它可能只需要3-5分钟，否则它不得不失败。

我在AWS中使用m3.medium实例进行这些测试。

在此之前，我在一小时内使用了t2.micro服务器和100个线程。一切都很好，我的意思是所有线程都是在几分钟内创建的，并且一直运行到小时之内。

我添加了摘要的最后几行。

summary + 840 in 00:00:25 = 33.1/s Avg: 6989 Min: 19 Max: 69102 Err:  3 (0.36%) Active: 591 Started: 591 Finished: 0 
summary = 424179 in 00:59:03 = 119.7/s Avg: 2963 Min: 19 Max: 137203 Err: 498 (0.12%) 
summary + 1542 in 00:01:31 = 17.0/s Avg: 36302 Min: 19 Max: 136434 Err: 388 (25.16%) Active: 4 Started: 683 Finished: 679 
summary = 425721 in 01:00:33 = 117.2/s Avg: 3084 Min: 19 Max: 137203 Err: 886 (0.21%) 
summary + 171 in 00:00:30 = 5.7/s Avg: 367 Min: 178 Max: 920 Err:  0 (0.00%) Active: 8 Started: 858 Finished: 850 
summary = 425892 in 01:01:03 = 116.3/s Avg: 3082 Min: 19 Max: 137203 Err: 886 (0.21%) 
summary + 149 in 00:00:24 = 6.1/s Avg: 352 Min: 162 Max: 992 Err:  0 (0.00%) Active: 0 Started: 1000 Finished: 1000 
summary = 426041 in 01:01:28 = 115.5/s Avg: 3081 Min: 19 Max: 137203 Err: 886 (0.21%)

那么有人可以提出这种情况的解决方案吗？

Thread Group - screenshot

summary + 1507 in 00:01:30 = 16.7/s Avg: 34686 Min: 23 Max: 116663 Err: 258 (17.12%) Active: 588 Started: 588 Finished: 0 
summary = 404415 in 00:57:31 = 117.2/s Avg: 3111 Min: 19 Max: 116663 Err: 674 (0.17%) 
summary + 378 in 00:00:27 = 14.0/s Avg: 31968 Min: 33 Max: 112930 Err: 54 (14.29%) Active: 589 Started: 589 Finished: 0 
summary = 404793 in 00:57:58 = 116.4/s Avg: 3138 Min: 19 Max: 116663 Err: 728 (0.18%) 
summary + 1868 in 00:01:30 = 20.7/s Avg: 30655 Min: 19 Max: 116585 Err: 126 (6.75%) Active: 592 Started: 592 Finished: 0 
summary = 406661 in 00:59:28 = 114.0/s Avg: 3265 Min: 19 Max: 116663 Err: 854 (0.21%) 
summary + 896 in 00:01:06 = 13.7/s Avg: 21775 Min: 19 Max: 90675 Err:  8 (0.89%) Active: 476 Started: 593 Finished: 117 
summary = 407557 in 01:00:33 = 112.2/s Avg: 3305 Min: 19 Max: 116663 Err: 862 (0.21%) 
summary + 537 in 00:00:24 = 22.2/s Avg: 30182 Min: 171 Max: 88596 Err: 85 (15.83%) Active: 2 Started: 701 Finished: 699 
summary = 408094 in 01:00:58 = 111.6/s Avg: 3341 Min: 19 Max: 116663 Err: 947 (0.23%) 
summary + 165 in 00:00:30 = 5.5/s Avg: 288 Min: 167 Max: 803 Err:  0 (0.00%) Active: 4 Started: 868 Finished: 864 
... 
... 
summary = 412193 in 01:12:28 = 94.8/s Avg: 3311 Min: 19 Max: 116663 Err: 947 (0.23%) 
summary + 178 in 00:00:30 = 5.9/s Avg: 334 Min: 169 Max: 959 Err:  0 (0.00%) Active: 3 Started: 4979 Finished: 4976 
summary = 412371 in 01:12:58 = 94.2/s Avg: 3309 Min: 19 Max: 116663 Err: 947 (0.23%) 
summary + 178 in 00:00:30 = 6.0/s Avg: 326 Min: 172 Max: 1072 Err:  0 (0.00%) Active: 2 Started: 5156 Finished: 5154 
summary = 412549 in 01:13:28 = 93.6/s Avg: 3308 Min: 19 Max: 116663 Err: 947 (0.23%) 
summary + 175 in 00:00:30 = 5.8/s Avg: 343 Min: 173 Max: 1066 Err:  0 (0.00%) Active: 3 Started: 5332 Finished: 5329 
summary = 412724 in 01:13:58 = 93.0/s Avg: 3307 Min: 19 Max: 116663 Err: 947 (0.23%) 
summary + 168 in 00:00:30 = 5.6/s Avg: 352 Min: 175 Max: 1057 Err:  0 (0.00%) Active: 4 Started: 5501 Finished: 5497 
summary = 412892 in 01:14:28 = 92.4/s Avg: 3306 Min: 19 Max: 116663 Err: 947 (0.23%) 
summary + 179 in 00:00:30 = 6.0/s Avg: 335 Min: 168 Max: 914 Err:  0 (0.00%) Active: 1 Started: 5677 Finished: 5676 
summary = 413071 in 01:14:58 = 91.8/s Avg: 3304 Min: 19 Max: 116663 Err: 947 (0.23%) 
summary + 178 in 00:00:30 = 5.9/s Avg: 306 Min: 169 Max: 984 Err:  0 (0.00%) Active: 2 Started: 5856 Finished: 5854 
... 
... 
summary = 416548 in 01:24:58 = 81.7/s Avg: 3279 Min: 19 Max: 116663 Err: 947 (0.23%) 
summary + 175 in 00:00:30 = 5.9/s Avg: 322 Min: 172 Max: 935 Err:  0 (0.00%) Active: 3 Started: 9331 Finished: 9328 
summary = 416723 in 01:25:28 = 81.3/s Avg: 3278 Min: 19 Max: 116663 Err: 947 (0.23%) 
summary + 172 in 00:00:30 = 5.7/s Avg: 320 Min: 163 Max: 902 Err:  0 (0.00%) Active: 6 Started: 9506 Finished: 9500 
summary = 416895 in 01:25:58 = 80.8/s Avg: 3277 Min: 19 Max: 116663 Err: 947 (0.23%) 
summary + 175 in 00:00:30 = 5.8/s Avg: 319 Min: 168 Max: 908 Err:  0 (0.00%) Active: 3 Started: 9678 Finished: 9675 
summary = 417070 in 01:26:28 = 80.4/s Avg: 3276 Min: 19 Max: 116663 Err: 947 (0.23%) 
summary + 170 in 00:00:30 = 5.7/s Avg: 321 Min: 165 Max: 1287 Err:  0 (0.00%) Active: 4 Started: 9849 Finished: 9845 
summary = 417240 in 01:26:58 = 80.0/s Avg: 3275 Min: 19 Max: 116663 Err: 947 (0.23%) 
summary + 154 in 00:00:26 = 5.9/s Avg: 325 Min: 165 Max: 979 Err:  0 (0.00%) Active: 0 Started: 10000 Finished: 10000 
summary = 417394 in 01:27:24 = 79.6/s Avg: 3273 Min: 19 Max: 116663 Err: 947 (0.23%) 
Tidying up ... @ Sun Jul 30 09:16:26 UTC 2017 (1501406186446) 
... end of run

来源

2017-08-01 Farid Guliyev

绝对在1秒内启动1000个线程对于任何计算机来说都是一项艰巨的任务，有些甚至会导致崩溃，并且完全依赖于CPU，内存等系统资源。除非您有超级计算机，否则实际上不可能进行模拟。请分享Thread Group截图。 –

我已经添加了线程组的屏幕截图。谢谢。 –

Loooking到Amazon instances specifications：

Model vCPU Mem (GiB) SSD Storage (GB) 

m3.medium 1 3.75 1 x 4

我强烈怀疑，你将能够在1秒钟打完折1000个线程作为最有可能的情况下将耗尽资源，双检查即使用Amazon CloudWatch或JMeter's PerfMon Plugin

所以一定要确保其健康指标的Ĵ电表负载生成器具有足够的备用资源，就好像JMeter实例将被重载一样，它将不能够足够快地发送请求，所以尽管被测试的应用程序可能表现良好，但您将看到非常大的响应时间。

我会建议添加另一个实例，并在distributed mode上运行JMeter，这样你应该处于更安全的位置。

来源

2017-08-01 11:44:42

嗨德米特里，我想补充一点，我已经设置堆大小如下： -Xms2816m -Xmx2816m 因此，如果jmeter会使用更多的内存，它应该崩溃。为了更好的理解，我在m3.large中做了相同的测试。该实例具有15GB内存。但测试在500线程后崩溃。那么，为什么它不在m3.medium崩溃？此外，我已经在m3.medium中测试了10 000个并发用户一个小时。同样的结果，它在一个小时内使用了500-600个线程，并在30分钟内创建了其他（10000-500）。它做了10000线程。 –

我为10 000个并发用户添加了摘要日志。 –

Jmeter - 1000个并发用户不是同时创建的

回答

相关问题