Jmeter response time for parallel execution - jmeter

I am using Jmeter 5.2, the application i am testing i have split them transaction modules. When i execute the test plan, the elapsed time, latency and connect time were added together for a module in the aggregate report. Since some of the requests runs parallel in a module, that report didn't produce expected results.
Later, i have moved the request to bzm-parallel controller modules. Where, some of the requests fails since some of the requests has to be executed after the previous request.
Is there any way to calculate the exact timetaken for the execution of 1 module in Jmeter considering the parallel execution of requests?


Cumulative execution time of parallel requests equals to the execution time of the longest request so you need to take only that request which elapsed time exceeds its neighbors.
In order to filter out "not interesting" requests you can use one of below optoins:
Put parallel requests under the Transaction Controller
If you're using HTML Reporting Dashboard for results analysis you can consider jmeter.reportgenerator.exporter.html.series_filter property
You can remove the samplers you're not interested in via Filter Results Tool


You can use a Simple controller inside your Parallel controller. This will help you execute the samples in parallel and in the correct sequence as arranged in the simple controller.
Sample:
Parallel Controller
Simple Controller
-- HTTP Sample 1
-- HTTP Sample 2
-- HTTP Sample 3
Output:
HTTP Sample 1
HTTP Sample 2
HTTP Sample 3

Related

java.lang.RuntimeException: Attempting to reset the thread name -> Jmeter Error while execution

When I execute my jmeter script with below mentioned scenario then I get java.lang.RuntimeException in the logs and 2nd iteration/loop count APIs are not executed.
As you can see only for 1 thread APIs are visible in view result tree.
In this you can see that no APIs are executed for 2nd thread.
Runtime exception is coming.
Thread Properties
Number of threads : 1
Ramp-up period : 1
Loop Count : 2
Thread Group Used : Normal Thread Group
Controller Used : Parallel
Data is parameterized using 1 csv file only.
I also used "Transaction Controller" to verify but in that I didn't faced any issues and the threads were executing for the mentioned loop count. Is it normal in case of parallel controllers?

As per "Limitations" chapter of the Parallel Controller documentation
Parallel Controller does not support work with Transaction Controller so if used you can get an unexpected results. If you decide to use these controllers together familiarize yourself with already known problems that described in roadmap
So my expectation is that you need to remove either Transaction or Parallel controller from your test plan.
Parallel Controller is for "exotic" scenarios like handling AJAX requests when a single JMeter's thread (virtual user) kicks off one or more sub-threads
If in the reality your "Scan_API" requests are sequential - you need to remove the Transaction Controller and implement concurrency on Thread Group level
If in the reality all the "Scan_API" requests are executed at the same moment, i.e. when one user "scans" something 13 concurrent requests are fired - then you need to remove the Transaction Controller because you don't really need it, the total execution time of the "scan" would be the time of the longest request so Parallel Controller in "parent sampler" mode will return you the slowest request execution time and that would be the value you're looking for.
More information: How to Use the Parallel Controller in JMeter

How to get both parent and child samples in Jmeter specifically for Parallel Controller

I am working on a use case where I have to hit multiple API end-points in parallel. I need to capture the response time of all the end-points and also the highest response time. By checking the Generate parent sample for Parallel controller I am getting the highest response time but then I am not getting the response time for child samples(all end-points). If I don't check the Generate parent sample then only the response time of end-points I am able to see in report and not the highest response time.

I don't understand what you're talking about, if I add View Results Tree listener I'm able to see both highest and individual response times:
The same applies to JMeter test execution in command-line non-GUI mode, the .jtl results file contains 3 entries: individual response times and the highest one:
timeStamp,elapsed,label,responseCode,responseMessage,threadName,dataType,success,failureMessage,bytes,sentBytes,grpThreads,allThreads,URL,Latency,IdleTime,Connect
1645003103393,1916,bzm - Parallel Controller,200,OK,Thread Group 1-1,,true,,14450,351,1,1,null,0,0,0
1645003103597,593,example.com,200,OK,Thread Group 1-1,text,true,,1046,113,1,1,http://example.com/,585,0,435
1645003103597,1712,jmeter.apache.org,200,OK,Thread Group 1-1,text,true,,13404,238,1,1,https://jmeter.apache.org/,764,0,435

How to set think times between HTTP requests in bzm -Parallel Controller

I am trying to set think times inside a "bzm-Parallel Controller" between HTTP-Requests, but unfortunately without success.
In my attached test plan I tried to test the parallel controller with 3 requests, but all 3 requests will be started at the same time.
enter image description here
I want to set think times of 100-200 ms between each request.
Is there a possibility to configure the "bzm-Parallel Controller" in this way or is it only possible between "normal" requests without a parallel controller?

bzm-Parallel Controller is something that is executing its children in parallel, to wit all 3 MetadataX requests will be started at exactly the same moment.
If you want a delay between these requests - move them outside of the bzm-Parallel Controller
More information on the concept:
Parallel Sampling for JMeter
How to Use the Parallel Controller in JMeter

response time values in aggregate report does not make sense in jmeter

I did a run with 400 Vus with following settings:
-> A Transaction controller as "Launch" with 1 request under it.The option to include timer & pre-post processor was disabled.
The 90%tile response time in aggregate report shows 8.9 sec for the request and 65 sec for the Launch transaction.
So,I am not getting as how the complete transaction takes 65 sec while the request takes around 9 secs

Putting just 1 request under Transaction Controller does no make any sense as the values from the request and from Transaction Controller will be the same.
The whole idea of the Transaction Controller is getting view of how long request sequence took, i.e. if you have end-to-end scenario consisting from several individual requests you might be interested in how long did it take to execute them all.
See Using JMeter's Transaction Controller guide for more details on Transaction Controller use cases and clarification on configuration options.
If you have only one request under Transaction Controller and still obtain different results for the request itself and for the transaction it may indicate resource lack on JMeter side, i.e. load generator machine is short on RAM or CPU or you have memory-intensive listener enabled. See JMeter Performance and Tuning Tips for a checklist and configure your JMeter accordingly.

Within a thread, are JMeter HTTP request/responses done sequentially?

I'm trying to understand the basics of JMeter. I've got a "plus1" Java servlet that adds one to a request parameter and returns the result, so it's a fast test servlet just so I can understand load testing.
Here's my test plan:
Thread Group: 1 thread, ramp up 1 s, loop count 10000
HTTP Request to localhost
Graph Results
Summary Report
When I run this, the summary report shows a throughput number of 200/sec or so.
The key question, with no controllers in the test plan, is JMeter running the test plan (sending a single request) and waiting for the response before looping?
When I introduce a more computationally intensive page for the request, the throughput number goes down as I would expect.

In short, yes.
There is an argument for having a sampler that would make a request and not wait for the response but it's an edge case. In most cases you would want a testing tool to wait to see what happens and verify things. It's also more realistic, most users will wait for a response, in fact they generally have to, before making subsequent calls.
If you want to run a capacity test then the best approach, I think, is to spread the load over multiple threads and to actually throttle the throughput of each one - you can do this using a Constant Throughput Controller. Eg. You could have 500 threads each running at 60 requests per minute, this would give a total load of 500 reqs/sec. This way, your test load is predictable and stable - it won't be linked to the speed of response from the server. Note. with multiple threads you'll want a ramp up period and you might find you have to spread the test over multiple machines (known as 'distributed' testing if you're going to google it).

Resources