Negative Active Thread Count in JMeter - jmeter

We're getting negative thread count in JMeter for active threads.
The test plan contains various Http Web Test Plan related components and samplers using Parallel Controller. This is creating problems for us in getting correct metrics as JMeter is emitting the same -ve values to the listeners for active threads. Any insights what might be wrong and how to fix this?
Here's the screenshot from the test plan while executing -

First of all don't run JMeter in GUI mode, it's only for tests development and/or debugging, when it comes to test execution you should run JMeter in command-line non-GUI mode
I don't think you should have Parallel Controller as the first parent sampler, the most obvious use case is simulating AJAX requests, concurrency should be set on Thread Group level

Related

JMeter pressure sometimes can not stop the thread

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

How can I load reversely On JMeter in Non-GUI

I am using JMeter in Non-GUI environment.
I am increasing load now, e.g. 1...5000, but I want to decrease load gradually, e.g. 5000...1
Is it possible?
I can't use GUI env.
The easiest way is going for Custom Thread Groups plugins, for example:
Ultimate Thread Group
Stepping Thread Group
You can install these Thread Groups as a part of Custom Thread Groups bundle using JMeter Plugins Manager
Alternatively you can also use Timers to introduce ramp-down logic, however it will be mostly dependent on your application response time
More information on above approaches: How to Ramp Down in JMeter

JMeter - Execution Order?

I have a test plan configured as so -
When I execute the test plan, all 3 simple controllers are executed at the same time, even though I have 1 thread set and 1 loop...
I want it to execute samples in "XML Import" then "UI - Quick Entry" then "UI - Reprint" rather than them all being executed at the same time..
I'm sure its obvious and I'm missing something. I am confused as to why this is happening.
Thanks
You can have only one Firefox Driver Config element per Thread Group, each thread (virtual user) will kick off a separate browser instance.
JMeter executes samplers upside down (unless you have Logic Controllers specifying different behaviour). See Using Selenium with JMeter's WebDriver Sampler for more details on Selenium and JMeter integration.
I had to move the two webdrivers into their own threads, this is now working as I expected it to.

Calls at the end of script execution are failing in jmeter

We observed that while executing the below scenario, calls at the end of script execution are failing and they are counted as part of error %,
Scenario:
Number of threads : 100 (even for 50 , 150 200 users, only the calls which are shown at the end of results tree are failing)
Ramp up period : 5s
Scheduler duration : 600s
We also observed that though the sceduled time is for 10mins(600s), jmeter runs for 11mins. Is there any option in jmeter for a ramp-down period?
This may happen when JMeter forcibly terminates running threads, ideally that should not be happening and threads should be stopped gracefully.
The most possible reason is simply lack of resources as you are using JMeter in a not very correct way.
You should not use JMeter GUI for tests execution, GUI mode is only for tests development and debugging
You should not use any listeners during test execution. Run your test in non-GUI mode, store results into .jtl file and after test finishes either generate HTML Reporting Dashboard or open the results file with the listener of your choice, but do this after test completion, not during the test.
With regards to "ramp-down" period: there are some custom Thread Groups available via JMeter Plugins project like Stepping Thread Group or Ultimate Thread Group which allow you to set up arbitrary rampdown patterns:

Endurance testing using Jmeter

I am new to Jmeter and trying to understand what all can be achieved using Jmeter. I want to perform endurance or soak testing of a application using Jmeter, i.e. I want to run a particular script for a particluar number of users for a period of 3 hours.
What all options are available to me and what is the best availablelistener to monitor the result?
Please help. Kindly add if I am missing anything that I should know before starting with soak testing?
For setting up the numbers of users and runtime of the test you use a Thread Group. Setting the runtime is done by checking the Scheduler check-box and specifying Duration.
Of the original listeners in JMeter I have found myself most oftenly just using the plain Summary Report. But JMeter Plugins gives additional listeners which may be better, it depends on what you want to measure. The JMeter Plugins also gives additional thread groups, where you can specify e.g. an increasing load over time.
Use a Thread Group to set up your number of users and the duration of your test (using the scheduler of the Thread Group).
Then add all the samplers and logic controllers you need to perform your testing.
Next, add a Summary Report listener to get an overview of your results (min/max/average and such), and add a View Result Tree listener to get an overview of EACH step your testplan is taking. This Tree listener is great to actually see what jmeter is doing, and to debug your tesplan.
BTW: if you add a HTTP Request Defaults object, you can set your URL and options in there, and don't need to add it to each and every sampler again. Especially works like a charm if you start using regexp extractors and such.

Resources