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個併發用戶不是同時創建的

回答

相關問題