JMeter pressure sometimes can not stop the thread - performance

After setting the duration of JMeter, sometimes several threads will fail to stop. No requests will be found, and no errors will be reported. The interface service will not stop the last few threads even after the JMeter is shut down

You're violating probably the most important JMeter Best Practice:
GUI mode is only for tests development and debugging, when it comes to test execution you should be running it in command-line non-GUI mode and this is what JMeter says each time you launch it:
If you still want to know the reason of thread getting stuck - take a thread dump (if you can use the GUI still):
and inspect what this thread is doing and where/by what it's blocked. If you cannot use GUI the thread dump can be taken by command-line tools
More information on JMeter tuning for maximum performance: 9 Easy Solutions for a JMeter Load Test “Out of Memory” Failure

Related

Jmeter CLI stops tests after sometime. Any ideas?

When I run Jmeter from Windows CLI, after some random time, the tests are being stopped or stuck. I can click on ctrl+C (one time) just to refresh the run but part of the request will be lost during the time it was stuck.
Take a look at jmeter.log file, normally it should be possible to figure out what's wrong by looking at messages there. If you don't see any suspicious entries there - you can increase JMeter's logging verbosity by changing values in logj2.xml file or via -L command-line parameters.
Take a thread dump and see what exactly threads are doing when they're "stuck"
If you're using HTTP Request samplers be aware that JMeter will wait for the result forever and if the application fails to respond at all - your test will never end so you need to set reasonable timeouts.
Make sure to follow JMeter Best Practices
Take a look at resources consumption like CPU, RAM, etc. - if your machine is overloaded and cannot conduct the required load you will need to switch to distributed testing
There are several approaches to debugging a JMeter test which can be combined as a general systematic approach that I capable of diagnosing most problems.
The first thing that I would suggest is running the test within the JMeter GUI to visualize the test execution. For this you may want to add a View Results Tree listener which will provide you with real time results from each request generated:
Another way you can monitor your test execution in real time within the JMeter GUI is with the Log Viewer. If any exceptions are encountered during your test execution you will see detailed output in this window. This can be found under the Options menu:
Beyond this, JMeter records output files which are often very useful in debugging you load tests. Both the .log file and the .jtl file will provide a time stamped history of every action your test performs. From there you can likely track down the offending request or error if your test unexpectedly hangs:
If you do decide to move your test into the cloud using a service that hosts your test, you may be able to ascertain more information through that platform. Here is a comprehensive example on how to debug JMeter load tests that covers the above approaches as well as more advanced concepts. Using a cloud load test provider can provide your test will additional network and machine resources beyond what your local machine can, if the problem is related to a performance bottleneck.

Jmeter How to stop the execution of all threads when find error in thread

I am new to Jmeter
I just wanted to stop the execution of all threads when find error in any of the threads.
I gone through many blogs and I used Action to be taken after Sampler error as Stop Thread and Stop thread etc.
Still I didn't see threads getting stopped in Jmeter GUI.
What to use if I want to see thread stopping when find any error while running threads.
Eg
Threads :500
Rampup: 5 Sec
If thread fail at 450 thread then I should see
#samples as 450 amd error % as 0.01(or something )in Summary report.
Is it possible?
It is possible only if you run your test with 1 thread, when you have more than one thread you will run into the situation when there are several threads online executing Samplers and when the error occurs JMeter will either ask threads to stop or tell them to stop resulting in more sample results than you expect.
Also according to JMeter Best Practices you're not supposed to be running your test in GUI mode, it's only for tests development and debugging, when it comes to test execution you need to run your JMeter tests in command-line non-GUI mode like:
jmeter -n -t test.jmx -l result.jtl
However it doesn't explain the results you're getting, I wouldn't expect exactly 1000 sample results given your configuration so if you want to get to the bottom of the issue you will need update your question with test plan overview, .jtl file and jmeter.log file contents.

Ubuntu : Execution was not ending properly before test completion

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

Jmeter load test is not getting over at given time

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.

Threads keep running even after test finishes in Jmeter

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.

Resources