While executing script using JMeter in non gui mode and remote testing i'm getting error message, how can I fix the problem
summary = 0 in 00:00:00 = ******/s Avg: 0 Min: 9223372036854775807 Max:
-9223372036854775808 Err: 0 (0.00%)
Tidying up remote # Sun Jan 07 21:00:11 EST 2018 (1515376811888)
... end of run
The JVM should have exitted but did not.
The following non-daemon threads are still running (DestroyJavaVM is OK):
Thread[Thread-5,5,main], stackTrace:java.net.DualStackPlainSocketImpl#accept0
java.net.DualStackPlainSocketImpl#socketAccept at line:131
java.net.AbstractPlainSocketImpl#accept at line:409
java.net.PlainSocketImpl#accept at line:199
java.net.ServerSocket#implAccept at line:545
java.net.ServerSocket#accept at line:513
bsh.util.Sessiond#run at line:71
java.lang.Thread#run at line:748
Thread[DestroyJavaVM,5,main], stackTrace:
Thread[Thread-3,5,main], stackTrace:java.net.DualStackPlainSocketImpl#accept0
java.net.DualStackPlainSocketImpl#socketAccept at line:131
java.net.AbstractPlainSocketImpl#accept at line:409
java.net.PlainSocketImpl#accept at line:199
java.net.ServerSocket#implAccept at line:545
java.net.ServerSocket#accept at line:513
bsh.util.Httpd#run at line:70
java.lang.Thread#run at line:748
The exception comes from daemon thread, as described here:
JMeter will exit all the non-daemon threads it starts, but it is possible that some non-daemon threads may still remain; these will prevent the JVM from exiting. To detect this situation, JMeter starts a new daemon thread just before it exits. This daemon thread waits a short while; if it returns from the wait, then clearly the JVM has not been able to exit, and the thread prints a message to say why.
From the exception details it appears that you have some socket connections. Those could be HTTP Samplers, some other samplers that open sockets or custom scripts. By default the daemon thread waits for 2 seconds, so if timeouts on any samplers are longer, it could be that daemon simply needs to wait longer (or you need to make timeouts shorter).
So:
Check your script and figure out what are the timeouts of the samplers. Either set them to numbers < 2 seconds, or change the following setting in jmeter.properties to be higher than the maximum timeout value:
jmeter.exit.check.pause=...
For example if your sampler is configured to wait for 30 sec., set this value to 32 sec.
If it doesn't help, it's likely that there's some bug in underlying library. In that case you can't really solve it, but you can use a fairly brutal workaround:
If the property jmeterengine.stopfail.system.exit is set to true (default is false), then JMeter will invoke System.exit(1) if it cannot stop all threads. Normally this is not necessary.
So set the following property to true as described here:
jmeterengine.stopfail.system.exit=true
As help says, normally it's not necessary, but if threads are really stuck, there's no much choice.
It seems you have either custom code or some plugin that does not handle correctly exit as per this root stack trace:
bsh.util.Httpd#run at line:70
So check this script or report a bug for it.
I've got the same problem right now (I'm on version 4.0 of jmeter) and the solution was disable the beanshell server on jmeter.properties.
just comment beanshell.server.port=9000 in file jmeter.properties
I have experienced this error in a distributed setup with Bean Shell server running on both master and slave nodes, where all were using same jmeter.properties config per https://jmeter.apache.org/usermanual/best-practices.html#beanshell_server:
beanshell.server.port=9000
beanshell.server.file=../extras/startup.bsh
Error was gone after removing those lines from master node jmeter.properties.
Most likely your JMeter is overloaded, i.e. you are trying to kick off too many threads on a machine having low hardware specifications or you didn't properly tune JMeter for high loads or both.
Make sure you're following JMeter Best Practices
Make sure you're following recommendations from Load Test running User Manual chapter
Set up monitoring of essential OS level health metrics (CPU, RAM, Swap, Disk and Network usage). Modern operating systems normally come with a set of utilities, alternatively you can use JMeter PerfMon Plugin, this way you will be able to correlate main performance metrics with resource utilisation. JMeter must have enough headroom to operate as if JMeter won't be able to send requests fast enough you won't be able to conduct the planned load
Related
I am running a load test using JMeter with 200 users for approx 1hr. So, the observation is that a few threads are stuck even after the duration completes. Like 60 out of 200 get stuck. When I take the thread dump and observe that these threads are in a Runnable state. Any suggestions for resolving this issue? And I do not see anything meaningful from the JMeter log file.
You will find an unexpected increase in response time at the end of that time.
This is because of the thread's insufficient ramp-down time. Some of your threads were active and made requests to the server and didn't receive the response but threads were closed forcefully. If your JMeter test is stopped forcefully, all the active threads will be closed immediately. So the requests generated by those threads will get higher response time.
You can use Ultimate Thread Group for graceful shutdown time(ramp-down time) of threads just like the ramp-up time.
Here is an example setting:
This is not a normal behaviour for a JMeter test, most probably it indicates that either JMeter engine is overloaded (not properly configured for high loads) or the machine where JMeter is running is overloaded (i.e. lacks RAM and starts intensive swapping)
Make sure to follow JMeter Best Practices (run your test in non-GUI mode, remove all Listeners and test elements you don't need, increase JMeter heap size, etc.)
Make sure to monitor the essential health metrics of the machine where JMeter is running (CPU, RAM, Network and Disk IO, Swap file usage). You can use JMeter PerfMon Plugin for this if you don't have any better software
It might be the case you'll have to switch to Distributed Testing, 200 virtual users doesn't seem to be a "high" load to me, but it depends on what exactly these users are doing, if they're uploading/downloading large files it may be sufficient to cause the problems
Going forward consider adding the thread dump and jmeter log file contents to your question as it doesn't contain any clues so we can only come up with "blind shot" answers
You may want to check your HTTP timeouts.
I usually set Connect Timeout to 5000 milliseconds, and Response Time out to 30000.
Your values may vary for your specific environment/ application.
In this way, if things go bad on the server under test, all requests terminate within the timeout (with errors).
You have also to consider that, if you are retrieving an HTML page with all its embedded objects, and the web server is stuck, you need to wait for multiple timeouts to expire before the operation terminate.
Ubuntu: Execution was not ending properly before test completion
I have two questions
1) I am running 4500 users test from two machines (2250+2250). Duration of the test is 1 hr 30 min.
At the end test was not closing and it's not giving a consolidated summary in the console.
2) after closing the test by keys(ctrl +C). If I open the jtl report from the master system its showing 2250 users in the (Active threads over time) Lisner.
Using ctrl+c is not enough for terminating the running process.
End your test by executing the shutdown.sh (or bat depending on your environment) to signal the running process to properly and gracefully end its execution. See here: http://jmeter.apache.org/usermanual/get-started.html
Edit: you can use the stoptest.cmd|sh for forcing a stop.
Looking into your execution log file my expectation is that your are kicking off 9000 threads. When it comes to remote testing JMeter Remote Engines are absolutely independent so each engine is executing the Test Plan it receives from the master.
If you define 4500 threads in the Thread Group(s) it means that every JMeter slave will kick off 4500 virtual users.
The fact that JMeter doesn't respond to Shutdown event indicates the fact that JMeter engines are overloaded so they even cannot gracefully shutdown in a reasonable time. Make sure you have monitoring of at least baseline CPU and Memory stats of JMeter load generators to ensure that they have enough headroom to operate as if they will be lacking resources it will result in the increased response time (and impossibility to shut the test down as well).
So my recommendations are:
Make sure the load you deliver matches your expectations as I am under the impression you are delivering twice as many users
Make sure you have monitoring of CPU, RAM, Network and Disk capacity on JMeter load generators, you can use i.e. JMeter PerfMon Plugin for this.
Make sure you're following JMeter Best Practices and recommendations from the 9 Easy Solutions for a JMeter Load Test “Out of Memory” Failure
I'm running Jmeter load test from command prompt for about one hour and test is not ending at one hour. It is taking more time that one hour.
I'm getting errors in Jmeter logs for failed transactions:
Non HTTP response code: java.net.SocketException
Non HTTP response message: Unexpected end of file from server
Please advise. Is it because of some threads is hanging and how to rectify it.
Thank you
Most probably you didn't set Connect and Read Timeout in Http Request default.
So if you server hangs, JMeter will wait infinitely for the response.
Beside ensure you set correct values in your scheduler.
If issue persists, please give more details with screenshot.
By default JMeter "asks" threads to stop and waits for their graceful shutdown. If threads cannot be stopped in a timely fashion you have the following options:
Implement a "hard stop", i.e. instead of "asking" threads to stop you need to "tell" them to stop. It can be done using i.e. Test Action sampler with Stop now action. (remember that in this case JMeter won't wait for graceful shutdown and you will get extra errors connected with abnormal threads termination)
The fact that JMeter threads are stuck may indicate problem with your application so I would recommend checking baseline health metrics on the application under test side using i.e. JMeter PerfMon Plugin. If there is enough headroom but it still works slowly or doesn't work at all it might indicate a bottleneck in your application code or infrastructure.
Also make sure you are following JMeter Best Practices and make sure your JMeter load generator(s) have enough CPU, RAM, etc. as in some cases JMeter can report "false negative" results due to lack of hardware resources.
I am running 24 Hr load test on jmeter with 3256 threads. But even after 28 hrs some of the threads keep running and does not get ramp down. There are several errors in the run.
Even when I choose to stop the threads,"Shutting down all the threads, please be patient" Pop up appears and stays forever and no threads are ramping down.
For your information:- Number of threads-3256; Ramp up period-300; Loop Count-192
Considering all the think/wait time in the script , scenario should run for 24Hrs.
How can I close all the threads forcefully.
There are following options available:
JMeter is listening to shutdown messages on port 4445. There are 2 scripts in /bin folder of your JMeter installation:
shutdown.cmd(sh) - send graceful shutdown request to all threads
stoptest.cmd(sh) - force stop threads
Use Test Action Sampler "Stop Now" option for "All Threads"
Use Beanshell Sampler with the following code:
SampleResult.setStopTestNow(true);
However in that way you can get lots of errors caused by force shutting down of test threads which will be in your test results.
Actually I think that behavior your're experiencing is being caused by lack of resources on your load generator (JMeter) side. Try following recommendations from JMeter Performance and Tuning Tips guide to see if it helps (you don't need to wait all 24h, it will be enough to wait till all threads are ramped up).
If adjusting JMeter parameters won't help it looks like that you'll need to consider distributed testing and generate the load from more than one host.
I am trying to simulate 100 threads request with 4 different users, all the 97 requests were sent and received but the remaining 3 requests still showing as executing.
I have to manually stop the Jmeter and then only the remaining request are passed.
Why is this happening?
Your machine probably doesn't have the resources to execute the requests or Java isn't configured appropriately. Take a look at this article and this one
In case you are running jmeter in a window mode, please check for attributes provided for heap memory etc. (those should not exceed more than half of the RAM on the machine you are running upon)