JMeter停止發送特定線程的HTTP請求

Question

我正在使用JMeter 2.11。 以下參數在jmeter.bat文件中定義

組HEAP = -Xms512m -Xmx12144m 設置NEW = -XX：新尺寸=128米-XX：MaxNewSize =128米設置SURVIVOR = -XX：SurvivorRatio = 8 -XX ：TargetSurvivorRatio = 50％組TENURING = -XX：MaxTenuringThreshold = 2 組RMIGC = -Dsun.rmi.dgc.client.gcInterval = 600000 -Dsun.rmi.dgc.server.gcInterval = 600000 組PERM = -XX：PermSize = 64m -XX：MaxPermSize = 64m

該測試以批處理模式啓動。 jmeter結果以XML格式存儲在jtl文件中。

我們做了一個需要while語句的場景。 如果我們刪除while語句，JMeter可以同時處理50個用戶。

如果我們添加while語句，大約80％的JMeter用戶線程被正確執行（40個用戶在執行場景時沒有任何問題）。 JMeter用戶線程的20％在變量期間停止：有時15分鐘，有時40分鐘，有時1小時，然後場景繼續與下一個語句相關（10個用戶正在啓動請求，然後在15分鐘內停止，例如，然後重新開始）。

通過使用調試採樣器跟蹤活動，它通常在幾秒鐘的定時器之前或之後停止。例如，它在40分鐘內停止，40分鐘後它再次發送HTTP請求（問題是我的IIS應用程序會話超時，所有請求都失敗）。 看來，我們添加的調試採樣器越多，JMeter工作正常。 沒有日誌...

我們嘗試了以下內容：

• 變化JMeter.bat設置

• 升級版本的JMeter

• 增加計時器，以便在場景中要壓力較小

沒有用。我們仍然有這個問題。因此，我想知道JMeter是否已達到其最大容量。 需要注意的是注射器的CPU大概在60％左右，並且內存還可以。

我擔心的是50個用戶很低...我們需要處理1000個用戶的測試，我們不能購買20臺機器來處理注射器。

如果有人對這個問題有任何想法，我會很感激。

問候

西爾維

Answer 1

我覺得你的問題更關係到你的服務器放慢由於負載而事實上，你沒有設置HTTP請求超時意味着他們等到你的服務器響應。

因此，首先要做的事情是在HTTP Request Default element中設置連接和響應超時。

接下來的事情就是檢查你遵循最佳做法時的負載測試，看看這個：

• http://jmeter.apache.org/usermanual/best-practices.html

• http://www.ubik-ingenierie.com/blog/jmeter_performance_tuning_tips/

最後對您的GC調整，我建議你只需保留：

組HEAP = -Xms512m -Xmx12144m

組PERM = -XX：PermSize =64米-XX：MaxPermSize參數=64米

作爲總結JMeter會能夠加載測試而沒有任何問題1000名的用戶而且你不需要20臺機器:-)

Answer 2

事實上，我在上面用Connect timeout設置爲1000和響應超時設置爲2000的測試是在單個線程（用戶）上進行的。 因此，套接字錯誤可能是由於連接超時參數太低...

我更改這些參數，並將連接超時設置爲60 000（1分鐘）和響應超時爲360 000（6分鐘，因爲有時我們有請求不發送回覆，我們將它們限制在5分鐘內，這是非常罕見的，但這是阻止情況）。

我刪除了這個從JMeter.bat文件：

set NEW=-XX:NewSize=128m -XX:MaxNewSize=128m 
set SURVIVOR=-XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=50% 
set TENURING=-XX:MaxTenuringThreshold=2 
set RMIGC=-Dsun.rmi.dgc.client.gcInterval=600000 -Dsun.rmi.dgc.server.gcInterval=600000 set PERM=-XX:PermSize=64m -XX:MaxPermSize=64m 

我在批處理模式下播放我的情況與50個用戶。看起來，我們不再有被阻塞的線程。不幸的是，我們看到以下對於我們的大多數用戶：請求被播放，服務器響應具有良好的延遲（小於一秒），並且下一個請求在一小時後播放，這給出了500 HTTP錯誤....

例如：如果我們看看單元Group6。以下是在JTL文件

<httpSample t="13" lt="13" ts="1410856270124" s="true" lb="/hopex/service.aspx?data=generationType-standard|generator-E98AEA3A4F717715" rc="200" rm="OK" tn="Groupe d'unités 1-6" dt="text" by="412"> 
 
    <java.net.URL>http://172.16.1.23/hopex/service.aspx?data=generationType-standard|generator-E98AEA3A4F717715</java.net.URL> 
 
</httpSample> 
 

 
**played at 16/09/2014 10:31:10** 
 

 

 
<httpSample t="0" lt="0" ts="1410856270138" s="true" lb="/hopex/statesessionprovider.aspx" rc="200" rm="OK" tn="Groupe d'unités 1-6" dt="text" by="238"> 
 
    <java.net.URL>http://172.16.1.23/hopex/statesessionprovider.aspx</java.net.URL> 
 
</httpSample> 
 

 
**played at 16/09/2014 10:31:10** 
 

 

 

 
<sample t="0" lt="0" ts="1410856274818" s="true" lb="Timer between steps" rc="200" rm="OK" tn="Groupe d'unités 1-6" dt="text" by="1478"/> 
 

 
**played at 16/09/2014 10:31:15** 
 

 

 
<httpSample t="3" lt="3" ts="1410860493293" s="false" lb="/Hopex/service.aspx?data=generationType-standard|generator-E98AEA3A4F717715" rc="500" rm="Internal Server Error" tn="Groupe d'unités 1-6" dt="text" by="298"> 
 
    <java.net.URL>http://172.16.1.23/Hopex/service.aspx?data=generationType-standard|generator-E98AEA3A4F717715</java.net.URL> 
 
</httpSample> 
 

 
**played at 16/09/2014 11:41:33**

大部分時間打和寫的，我們剛剛計時器後的問題。在這裏，你可以看到最後一個請求已經在前一個請求（這是一個JMeter定時器）之後超過一個小時播放...... 我們的應用程序日誌顯示最後一個請求從未發送到應用程序。 因此，這意味着JMeter在發送請求之前暫停了一個多小時。 應該注意的是，如果我們從我們的場景中刪除while語句，它就會起作用。 還應該注意的是，這些錯誤不適用於while語句附近。

由於您認爲服務器過載，我註冊了帶性能監視器的Windows指示燈。 看起來，測試期間的平均CPU大約爲10％（可能是因爲大多數線程停止）。如果我看看10:31，CPU不會超過30％。

如果我檢查了內存消耗，發現問題時有20 GB的RAM可用。

所以，我覺得服務器沒有超載......

我檢索JMeter的日誌信息。看起來問題來自JMeter堆棧溢出。我不知道如何解決這個問題。我試圖改變JMeter.bat參數，但我們有副作用。 這裏是JMeter的日誌的一部分：

2014/09/16 10:30:49 WARN - jmeter.control.GenericController: StackOverflowError detected 
 
2014/09/16 10:30:49 WARN - jmeter.control.GenericController: StackOverflowError detected 
 
2014/09/16 10:30:49 WARN - jmeter.control.GenericController: StackOverflowError detected 
 
2014/09/16 10:30:51 WARN - jmeter.control.GenericController: StackOverflowError detected 
 
2014/09/16 10:31:00 INFO - jmeter.reporters.Summariser: summary + 196 in 30s = 6.5/s Avg: 154 Min:  0 Max: 11347 Err:  0 (0.00%) Active: 50 Started: 50 Finished: 0 
 
2014/09/16 10:31:00 INFO - jmeter.reporters.Summariser: summary = 5974 in 1103s = 5.4/s Avg: 406 Min:  0 Max: 47864 Err:  0 (0.00%) 
 
2014/09/16 10:31:01 WARN - jmeter.control.GenericController: StackOverflowError detected 
 
2014/09/16 10:31:32 INFO - jmeter.reporters.Summariser: summary + 154 in 32s = 4.9/s Avg: 94 Min:  0 Max: 10982 Err:  0 (0.00%) Active: 50 Started: 50 Finished: 0 
 
2014/09/16 10:31:32 INFO - jmeter.reporters.Summariser: summary = 6128 in 1135s = 5.4/s Avg: 399 Min:  0 Max: 47864 Err:  0 (0.00%) 
 
2014/09/16 10:31:37 WARN - jmeter.control.GenericController: StackOverflowError detected

我就因爲現在1個月這個問題，我不知道如何解決它... 如果你有一個想法，我真的很感激。

問候

西爾維

Answer 3

我在JMeter.bat文件進行使用ThreadStackSize = 4096集的測試，我仍然有問題（我的情況是在批處理模式下啓動）。 下面的請求被髮送：

**Sent at 19/09/2014 12:06:06** 


<sample t="0" lt="0" ts="1411121166434" s="true" lb="------------------------Begin Loop Page de prop App From Tree " rc="200" rm="OK" tn="Groupe d&apos;unitأ©s APM 1-9" dt="text" by="923"> 

**sent at 19/09/2014 12:36:16** 


<sample t="0" lt="0" ts="1411122975778" s="true" lb="----------Technology " rc="200" rm="OK" tn="Groupe d&apos;unitأ©s APM 1-9" dt="text" by="923"> 

正如你所看到的，有2個請求

匹配JMeter的視圖之間30分鐘就以下事項：

「開始循環頁面支持應用程序從樹「是一個調試採樣器，它通過一個」如果創建範圍「這是一個」如果聲明「，其次是」循環創建技術「，其中循環設置爲1，如下所示：

其次是調試取樣「--------------技術」執行的調試取樣後30分鐘「開始循環頁德道具應用程序從一棵樹」。

使用的定時器是定時器。

應該指出，我在高斯定時器的另一場景中遇到同樣的問題。定時器值取決於操作，但是在2000毫秒和6000毫秒之間。 在另一種情況下，如果我刪除while語句，該場景有效......不幸的是，我需要while語句。 在這種情況下，問題似乎來自設置爲1的循環。

關於VisualVM工具，我剛剛看到垃圾收集器非常頻繁地完成。我沒有看到內存問題......但我會在下一次測試中看看它。

希望它可以幫助

問候

西爾維

[JMeter的StackOverflow上]的