JMeter stops sending HTTP Requests for specific threads - jmeter

I am using JMeter 2.11.
The following parameters are defined in the jmeter.bat file
set HEAP=-Xms512m -Xmx12144m
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
The test is launched in batch mode.
The jmeter results are stored in the jtl file in an XML Format.
We made a scenario that needs while statement.
If we remove the while statement, JMeter manages to handle 50 users concurrently.
If we add the while statement, around 80% of JMeter user threads are executed correctly (40 users are carrying out the scenario without any problem).
20% of JMeter user threads stop during a variable period : sometimes 15 minutes, sometimes 40 minutes, sometimes an hour and then the scenario keeps on with the next statement (10 users are launching requests and then stop during 15 min for example and then restart).
By tracing the activity with debug sampler, it just stops anywhere usually before or after a timer of a few seconds. It stops during 40 minutes for example and after 40 minutes, it sends again HTTP requests (the problem is that my IIS application session is timed out and all requests failed).
It seems that the more we add debug sampler, the more JMeter works correctly.
There is no log...
We tried the following :
Change JMeter.bat settings
Upgrade JMeter version
Increase timers in order the scenario to be less stressful
Nothing works. We still have the problem. I am therefore wondering if JMeter has reached its maximum capacity.
It should be noted that the injector CPU is around 60% and the memory is ok.
What I am afraid about is that 50 users is quite low... We need to handle tests with 1000 users and we cannot buy 20 machines to just handle the injectors.
If anyone has any idea concerning this problem, I would really appreciate.
Regards
Sylvie

I think your issue is more related to your server slowing down due to Load and the fact that you didn't set a timeout on Http Request meaning they wait until your server responds.
So first thing to do is set Connection and Response Timeout in a HTTP Request Default element.
Next thing is to check you follow best practices when load testing , see for this:
http://jmeter.apache.org/usermanual/best-practices.html
http://www.ubik-ingenierie.com/blog/jmeter_performance_tuning_tips/
Finally regarding your GC tuning, I suggest you just keep:
set HEAP=-Xms512m -Xmx12144m
set PERM=-XX:PermSize=64m -XX:MaxPermSize=64m
As a summary JMeter will be able to Load test without any problem 1000 Users and you won't need 20 machines for this :-)

I made a test using ThreadStackSize=4096 set in the JMeter.bat file and I still have the problem (My scenario is launched in batch mode).
the following requests are sent :
**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">
As you can see, there is 30 minutes between the 2 Requests
The matching JMeter View is the following:
"Begin Loop Page de prop App From Tree " is a debug sampler, it goes through a "If Create Scope" which is a "If Statement" followed by a "Loop Create Technology" where loop is set to 1 as shown below:
Followed by the debug sampler "--------------Technology" executed 30 minutes after the debug sampler "Begin Loop Page de prop App From Tree".
The timer used are Constant Timer.
It should be noted that I have the same problem in another scenario with Gaussian Timers. The timer values depend on the actions but are between 2000 ms and 6000 ms.
In the other scenario, if I remove the while statement, the scenario works... Unfortunately, I need the while statement.
In this scenario, the problem seems to come from the loop set to 1.
Concerning the VisualVM tool, I just saw that the garbage collector is done very frequently. I did not see memory problem... But I will have a look to it on the next test.
Hope it helps
Regards
Sylvie

In fact, the test I made above with Connect timeout set to 1000 and response timeout to 2000 was on a single thread (user).
So the socket error was probably due to a connect timeout parameter too low...
I change those parameters and set connect timeout to 60 000 (1min) and response timeout to 360 000 (6min because sometimes we have requests that do not send response and we limit them to 5 minutes, it is very rare but this was blocking the scenario).
I removed this from JMeter.bat file :
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
I played my scenario in batch mode with 50 users. It appears that we do not have anymore threads that are blocked. Unfortunately we saw the following for most of our users:a request is played, the server respond with good delay (less than one second) and the next request is played an hour later which gives a 500 HTTP Error....
Example : if we have a look at the unit Group6. The following is played and written in the JTL File
<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&apos;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&apos;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&apos;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&apos;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**
Most of the time, we have problems just after timers. Here, you can see that the last request has been played more than one hour after the previous one (which was a JMeter timer)...
Our application log shows that the last request has never been sent to the application.
So it means JMeter made a pause of more than one hour before sending the request.
It should be noted that if we remove the while statement from our scenario, it works.
It should be noted also that the errors do not apply near a while statement.
Since you were thinking that the server was overloaded, I registered Windows indicators with performance monitor.
It appears that the average CPU during the test was around 10% (probably because most of the threads stop). If I have a look at 10:31, the CPU does not go over 30%.
If I checked the memory consumption, there was 20 GB of RAM available when the problem occurred.
So, I think the server is not overloaded...
I retrieve this information from JMeter logs. It seems the problem comes from JMeter with stack overflow. I do not know how to solve this problem. I tried to change JMeter.bat parameters but we had side effects.
Here is a part of JMeter log :
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
I am on this problem since one month now and I do not know how to solve it...
If you have an idea, I would really appreciate.
Regards
Sylvie

Related

why soak test is ended before the time i set in jmeter?

i set up a 16-hour soak test in jmeter. use a csv file for different users for 10000 users. use ultimate thread group with these settings:
one row
start threads count: 20
initial delay: 0
start up time : 60 sec
hold for load : 57600 sec
shut down time : 10
i run the test 3 times. all of them ended in 8-9 hours.
on the server pc, i look for some settings of iis but didnt see anything.
the second day, in view result tree there was a response such that:
sampler result page
response message: non http response message: en established comnection was aborted by the software in your host machine.
does jmeter any limitation or iis have some timeout value?
JMeter doesn't have any internal "timeouts" for the test, it might be the case you test has.
For example I can think of 2 possible options:
Your CSV Data Set Config has either Recycle on EOF set to True or Stop thread on EOF set to False so when all 10000 lines are used the test stops
Your Ultimate Thread Group is configured to Stop Thread or Stop Test on the error and your test terminates when error occurs
The exact reason for stopping the test can be found in the jmeter.log file

Concurrency Thread Group and Throughput shaping timer

I want to simulate 100 rps for the application which I am working on. I am planning to use Concurrency Thread Group and Throughput shaping timer. I have created a sample example to test how it works. Below is my script
I have added this as the next line to log4j2.xml file:
<Logger name="kg.apc.jmeter.timers.VariableThroughputTimer" level="debug" />
jmeter.log has below logs
2021-07-21 14:11:22,402 INFO c.b.j.c.VirtualUserController: Need to decrease concurrency, thread is done: bzm - Concurrency Thread Group-ThreadStarter 1-217
2021-07-21 14:11:22,402 INFO o.a.j.t.JMeterThread: Thread is done: bzm - Concurrency Thread Group-ThreadStarter 1-217
2021-07-21 14:11:22,402 INFO o.a.j.t.JMeterThread: Thread finished: bzm - Concurrency Thread Group-ThreadStarter 1-217
2021-07-21 14:11:22,407 DEBUG k.a.j.t.VariableThroughputTimer: Calculating 407 380.0 38
2021-07-21 14:11:22,427 INFO c.b.j.c.VirtualUserController: Need to decrease concurrency, thread is done: bzm - Concurrency Thread Group-ThreadStarter 1-218
2021-07-21 14:11:22,427 INFO o.a.j.t.JMeterThread: Thread is done: bzm - Concurrency Thread Group-ThreadStarter 1-218
2021-07-21 14:11:22,427 INFO o.a.j.t.JMeterThread: Thread finished: bzm - Concurrency Thread Group-ThreadStarter 1-218
........
........
2021-07-21 14:11:23,007 DEBUG k.a.j.t.VariableThroughputTimer: Second changed 60.0 , waiting: 0, samples sent 94, current rps: 100.0 rps
2021-07-21 14:11:23,007 WARN k.a.j.t.VariableThroughputTimer: No free threads available in current Thread Group bzm - Concurrency Thread Group, made 94 samples/s for expected rps 100.0 samples/s, increase your number of threads
2021-07-21 14:11:23,007 DEBUG k.a.j.t.VariableThroughputTimer: Calculating 7 0.0 0
My question is
Q1. Have I configured my test correctly to simulate throughput of 100 rps or am I missing something ?
Q2. How do I calculate in advance how many users do I need to add in Target Concurrency? If I go with the formula
(rps * Maximum response time) / 1000
Here, do I need to add the Maximum response time of all the samplers from 1 to 6? or how?
Q3. How do we calculate the throughput?(refer 3rd image having Aggregate Report),
Is the Total Throughput = Adding Throughput of Sampler 1 to 6, which is = (15.8 + 15.8 + 15.8 + 15.7 + 15.6 + 15.6) = 94.3 rps. Is my calculation correct?
Q4. In the jmeter.log, it says "Need to decrease concurrency, thread is done: bzm - Concurrency Thread Group-ThreadStarter 1-217".
Does that mean number of threads(users) needed to simulate 100 rps are more and hence jmeter needs to decrease the threads(users)?
Then again in the logs, it says, "No free threads available in current Thread Group bzm - Concurrency Thread Group, made 94 samples/s for expected rps 100.0 samples/s, increase your number of threads"
Is it asking me (the user) to increase the thread or it is just the jmeter talking to itself? Jmeter already has 150 threads to use. Actually I started from 50 and then also I received the message to increase the no of threads then I increased the threads to 100 and I got the same message and then finally I increased it to 150 and still getting that message in the logs?
As you can see for the above image, at the 51th second, jmeter was using only 29 threads(users) out of 150. Which means it still has 121 threads left to use. Also, I observed that when I started the script, immediately 150 threads were in use but then they started rapidly decreasing and increasing. However, they never been to 150 during the 60 seconds run (150 threads wered used only at the start, for a fraction of seconds and then got reduced!)
Then why was the message in the logs to increase the users? infact there are users available which jmeter can use?
You only forgot to ask the "Q5": the Ultimate Question of Life, the Universe, and Everything
Q1. We don't know, it depends on the application response time, your 150 threads may or may not be sufficient to conduct the load of 100 requests per second
Q2. Go for the largest response time ever, according to JMeter threads model each thread waits for the previous request to finish before starting the next one so the whole sequence of 6 samplers will act at the speed of the slowest one.
Q3. Throughput Shaping Timer tries to reach and maintain the defined throughput for all the samplers in its scope so if you have 6 requests in scope the throughput for individual request would be 100 / 6
Q4. Need to decrease concurrency - the timer is "talking to itself" informing that it goes too fast hence need to shut down a couple of threads to slow down the requests rate. increase your number of threads is for you but I don't think it's applicable for your case, if you run the real test and will see tons of messages like this in the log it will indicate that the current amount is not sufficient to reach the target throughput
Don't run your test in GUI mode, it's only for tests development and debugging, when it comes to execution you must be using command-line non-GUI mode
According to JMeter Best Practices you should always be using the latest version of JMeter so consider upgrading to JMeter 5.4.1 or whatever is the latest stable version available at JMeter Downloads page

Requests and Threads understanding in JMeter logs

I am still confused with some JMeter logs displayed here. Can someone please give me some light into this?
Below is a log generated by JMeter for my tests.
Waiting for possible Shutdown/StopTestNow/Heapdump message on port 4445
summary + 1 in 00:00:02 = 0.5/s Avg: 1631 Min: 1631 Max: 1631 Err: 0 (0.00%) Active: 2 Started: 2 Finished: 0
summary + 218 in 00:00:25 = 8.6/s Avg: 816 Min: 141 Max: 1882 Err: 1 (0.46%) Active: 10 Started: 27 Finished: 17
summary = 219 in 00:00:27 = 8.1/s Avg: 820 Min: 141 Max: 1882 Err: 1 (0.46%)
summary + 81 in 00:00:15 = 5.4/s Avg: 998 Min: 201 Max: 2096 Err: 1 (1.23%) Active: 0 Started: 30 Finished: 30
summary = 300 in 00:00:42 = 7.1/s Avg: 868 Min: 141 Max: 2096 Err: 2 (0.67%)
Tidying up ... # Fri Jun 09 04:19:15 IDT 2017 (1496971155116)
Does this log means [ last step ] 300 requests were fired, 00.00:42 secs took for the whole tests, 7.1 threads/sec or 7.1 requests/sec fired?
How can i make sure to increase the TPS? Same tests were done in a different site and they are getting 132TPS for the same tests and on the same server. Can someone put some light into this?
In here, total number of requests is 300. Throughput is 7 requests per second. These 300 requests generated by your given number of threads in Thread group configuration. You can also see the number of active threads in the log results. These threads become active depend on your ramp-up time.
Ramp-up time is the speed at which users or threads arrive on your application.
Check this for an example: How should I calculate Ramp-up time in Jmeter
You can give enough duration in your script and also check the loop count forever, so that all of the threads will be hitting those requests in your application server until the test finishes.
When all the threads become active on the server, then they will hit those requests in server.
To increase the TPS, you must have to increase the number of threads because those threads will hit your desired requests in server.
It also depends on the response time of your requests.
Suppose,
If you have 500 virtual users and application response time is 1 second - you will have 500 RPS
If you have 500 virtual users and application response time is 2 seconds - you will have 250 RPS
If you have 500 virtual users and application response time is 500 ms - you will have 1000 RPS.
First of all, a little of theory:
You have Sampler(s) which should mimic real user actions
You have Threads (virtual users) defined under Thread Group which mimic real users
JMeter starts threads which execute samplers as fast as they can and generate certain amount of requests per second. This "request per second" value depends on 2 factors:
number of virtual users
your application response time
JMeter Summarizer doesn't tell the full story, I would recommend generating the HTML Reporting Dashboard from the .jtl results file, it will provide more comprehensive load test result data which is much easier to analyze looking into tables and charts, it can be done as simple as:
jmeter -g /path/to/testresult.jtl -o /path/to/dashboard/output/folder
Looking into current results, you achieved maximum throughput of 7.1 requests second with average response time of 868 milliseconds.
So in order to have more "requests per second" you need to increase the number of "virtual users". If you increase the number of virtual users and "requests per second" is not increasing - it means that you identified so called saturation point and your application is not capable of handling more.

java.net.SocketException:connection reset in JMeter [duplicate]

I have the next test plan in JMeter:
on the screenshot you can see the settings for the 1st ThreadGroup, wich has 50% of common amout of request in test plan (in each Thread Group are 10 different subrequests placed).
So, +1 request per second is added in average using these settings.
Then I ran this test and saw this picture (Error % column):
I save errors in file and all these errors have the same text:
<sample t="30129" lt="0" ts="1356710138314" s="false" lb="WebService(SOAP) Request 1" rc="000" rm="**Connection reset**" tn="jp#gc - Stepping Thread Group1 3-247" dt="text" by="0"/>
Server's cpu screenshot:
and for database:
After the errors have appeared my comp started work slowly and slowly (although the errors stopped to appear further)...
And in the same time the server's cpu progressively dropped to 0.
Could you tell me, please,
What is the reason of this error?
Have I reached the server timeout? (Because Max is more than 30s in the table).
UPD. I have rerun test with next settings: 1000 users per 02:46:40 (+1 Thread Group per 10 second and 10 requests inside each new Thread in the Loop).
I.e. I have reduced the time of test and total Thread Groups by 2 times, but save intensivity of Thead's adding.
The results are the same (including cpu usage on the server).
I've received the error «Connection reset» after 990 thread started. There are screenshots:
Any idea?
First, WebService(SOAP) Request is not the best way to test Webservices in JMeter, it will be deprecated in upcoming 2.9 version.
HTTP Sampler is the one to choose as it performs much better.
Second, Connection Reset means your server has cut connection. It could be coming from the CPU which seems high but it's not sure.
If what you call "my comp" is the computer hosting JMeter started working slowly then your JMeter instance is overwhelmed by the number of threads (2003 or more?) you've configured. It can come from a lot of factors, read this:
http://www.dzone.com/links/see_how_to_make_jmeter_run_thousands_of_threads_w.html

Error "Connection reset" in JMeter (SOAP XML web-service)

I have the next test plan in JMeter:
on the screenshot you can see the settings for the 1st ThreadGroup, wich has 50% of common amout of request in test plan (in each Thread Group are 10 different subrequests placed).
So, +1 request per second is added in average using these settings.
Then I ran this test and saw this picture (Error % column):
I save errors in file and all these errors have the same text:
<sample t="30129" lt="0" ts="1356710138314" s="false" lb="WebService(SOAP) Request 1" rc="000" rm="**Connection reset**" tn="jp#gc - Stepping Thread Group1 3-247" dt="text" by="0"/>
Server's cpu screenshot:
and for database:
After the errors have appeared my comp started work slowly and slowly (although the errors stopped to appear further)...
And in the same time the server's cpu progressively dropped to 0.
Could you tell me, please,
What is the reason of this error?
Have I reached the server timeout? (Because Max is more than 30s in the table).
UPD. I have rerun test with next settings: 1000 users per 02:46:40 (+1 Thread Group per 10 second and 10 requests inside each new Thread in the Loop).
I.e. I have reduced the time of test and total Thread Groups by 2 times, but save intensivity of Thead's adding.
The results are the same (including cpu usage on the server).
I've received the error «Connection reset» after 990 thread started. There are screenshots:
Any idea?
First, WebService(SOAP) Request is not the best way to test Webservices in JMeter, it will be deprecated in upcoming 2.9 version.
HTTP Sampler is the one to choose as it performs much better.
Second, Connection Reset means your server has cut connection. It could be coming from the CPU which seems high but it's not sure.
If what you call "my comp" is the computer hosting JMeter started working slowly then your JMeter instance is overwhelmed by the number of threads (2003 or more?) you've configured. It can come from a lot of factors, read this:
http://www.dzone.com/links/see_how_to_make_jmeter_run_thousands_of_threads_w.html

Resources