Bug 53159 - Enable parallel execution of Sampler for Same user to simulate Ajax Requests
Summary: Enable parallel execution of Sampler for Same user to simulate Ajax Requests
Status: NEEDINFO
Alias: None
Product: JMeter
Classification: Unclassified
Component: Main (show other bugs)
Version: 3.1
Hardware: All All
: P3 enhancement with 20 votes (vote)
Target Milestone: ---
Assignee: JMeter issues mailing list
URL:
Keywords:
: 41293 59352 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-04-28 14:52 UTC by Philippe Mouawad
Modified: 2018-10-01 14:16 UTC (History)
6 users (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Philippe Mouawad 2012-04-28 14:52:46 UTC
This feature has been asked for many times on user mailing list and seems important one to implement.
I open a enhancement request so we can discuss what's the best way to implement it:
- ParallelController
- Special sampler with child requests (close to concurrent download feature)
- ...
Comment 1 Milamber 2012-05-01 14:18:31 UTC
This is an issue on which I have given it some thinking:
Controller "parallel" seems a good option. If we follow the model of the Transaction Controller, which created a new SamplerResult to calculate the total time of the children elements.

We can do the same thing:
1 / Start the Parallel Controller
2 / Create a SamplerResult
3 / Create a thread pool (following Download Embedded resource model) with a configurable size
4 / Send HTTP requests (child) through the thread pool
5 / As and when of requests, concatenate the responses in the response data of SampleResult
6 / End of the execution of all applications of children Parallel Controller
7 / Calculate the total time of execution of the controller, update SamplerResult, back to the normal JMeter execution (post-processor, assertion, listeners for the controller parallel)


Constraints:
* The JMeter variables must be replaced before or during the course of Parallel Controller?
* What to do for the passage of elements pre-processor, post processors and Assertion of the children? Do not execute this kind of element for children, just for SamplerResult (post and assertion)
Is it necessary to prohibit anything other than HTTP requests in controller Parallel son. Do not put another controller (Simple, If, Loop, etc.) as child of PC?
Within the parameters of Parallel Controller, add the ability to schedule requests children (choice of sequencing, selection of the thread executing unit, etc..)
Comment 2 Philippe Mouawad 2012-05-01 17:02:03 UTC
Hi Milamber,

(In reply to comment #1)
> This is an issue on which I have given it some thinking:
> Controller "parallel" seems a good option. If we follow the model of the
> Transaction Controller, which created a new SamplerResult to calculate the
> total time of the children elements.
> 
> We can do the same thing:
> 1 / Start the Parallel Controller
> 2 / Create a SamplerResult
> 3 / Create a thread pool (following Download Embedded resource model) with a
> configurable size
> 4 / Send HTTP requests (child) through the thread pool
> 5 / As and when of requests, concatenate the responses in the response data
> of SampleResult
> 6 / End of the execution of all applications of children Parallel Controller
> 7 / Calculate the total time of execution of the controller, update
> SamplerResult, back to the normal JMeter execution (post-processor,
> assertion, listeners for the controller parallel)
> 
I rather agree until step 4.
My analysis lead me to the same idea of using ransactionController approach.
But then I think we will have to modify JMeterThread#process_sampler to handle a kind of ParallelRequestsSampler (like TransactionSampler) that will deliver the children Samplers.

> 
> Constraints:
> * The JMeter variables must be replaced before or during the course of
> Parallel Controller?
We will have to make JMeterContext thread-safe or have each child have a copy and merge at end of all children 

> * What to do for the passage of elements pre-processor, post processors and
> Assertion of the children? Do not execute this kind of element for children,
> just for SamplerResult (post and assertion)
I think Pre/Post processor should be executed on each of parallelController children but users should not make them dependant on each others as order is not guaranteed
This will make implementation more complex but I think it's required for correlation. 
In my experience of GWT Load Testing, I had to put Post Processor to correlate data for next set of requests. If PostProcessor were not executed then scripting would be far more complex.

> Is it necessary to prohibit anything other than HTTP requests in controller
> Parallel son. Do not put another controller (Simple, If, Loop, etc.) as
> child of PC?
I agree with limitation, only accept HttpSamplerBase
> Within the parameters of Parallel Controller, add the ability to schedule
> requests children (choice of sequencing, selection of the thread executing
> unit, etc..)
If they are parallel why control sequencing ?
Comment 3 Sebb 2012-05-02 01:12:49 UTC
I think we need to be very careful that any implementation does not grow in scope unnecessarily.

So I think we need to decide in advance what we are trying to model here.
This should help decide how best to implement post-processors etc, how to handle cookies etc.

We don't want to end up implementing a full browser.
Comment 4 Philippe Mouawad 2012-05-02 06:21:58 UTC
Hello,
On my side this feature should allow:
Parallel exécution of http sampler (or any sampler)
Exécution of assertions, pré-post processors

The main goal being to simulate today browser behaviour with Ajax.
But not simulate full browser ( no Javascript, CSS )

Regards 
Philippe
Comment 5 Milamber 2012-05-02 06:34:13 UTC
(In reply to comment #2)
> Hi Milamber,
> 
> (In reply to comment #1)
> > This is an issue on which I have given it some thinking:
> > Controller "parallel" seems a good option. If we follow the model of the
> > Transaction Controller, which created a new SamplerResult to calculate the
> > total time of the children elements.
> > 
> > We can do the same thing:
> > 1 / Start the Parallel Controller
> > 2 / Create a SamplerResult
> > 3 / Create a thread pool (following Download Embedded resource model) with a
> > configurable size
> > 4 / Send HTTP requests (child) through the thread pool
> > 5 / As and when of requests, concatenate the responses in the response data
> > of SampleResult
> > 6 / End of the execution of all applications of children Parallel Controller
> > 7 / Calculate the total time of execution of the controller, update
> > SamplerResult, back to the normal JMeter execution (post-processor,
> > assertion, listeners for the controller parallel)
> > 
> I rather agree until step 4.
> My analysis lead me to the same idea of using ransactionController approach.
> But then I think we will have to modify JMeterThread#process_sampler to
> handle a kind of ParallelRequestsSampler (like TransactionSampler) that will
> deliver the children Samplers.

This will complicate the task. Process_sampler method is critical for JMeter.
I think we should remain independent of the traditional engine of JMeter.

It may very well have a small motor to handle these parallel requests. This little motor starts with the entry of PC and stops at the end of PC.
This little engine will not do all things than process_sampler.

> 
> > 
> > Constraints:
> > * The JMeter variables must be replaced before or during the course of
> > Parallel Controller?
> We will have to make JMeterContext thread-safe or have each child have a
> copy and merge at end of all children 
> 
> > * What to do for the passage of elements pre-processor, post processors and
> > Assertion of the children? Do not execute this kind of element for children,
> > just for SamplerResult (post and assertion)
> I think Pre/Post processor should be executed on each of parallelController
> children but users should not make them dependant on each others as order is
> not guaranteed
> This will make implementation more complex but I think it's required for
> correlation. 
> In my experience of GWT Load Testing, I had to put Post Processor to
> correlate data for next set of requests. If PostProcessor were not executed
> then scripting would be far more complex.

If a set of requests waiting some inputs for PostProcessor, then this is a new PC after the first PC.
|--TG
|  |--PC1
|  |    |-- Child11
|  |    |-- Child12
|  |    |-- Child13
|  |    |-- PostProcessor (only on PC1 response data)
|  |--PC2
|  |    |-- Child21
|  |    |-- Child22
|  |    |-- Child23
|  |    |-- PostProcessor (only on PC2 response data)
|  |--Listener (show 2 results)

In my opinion, the PC just help to simulate (automatically or not) the parallel launch of xmlhttprequest resquests. 

> 
> > Is it necessary to prohibit anything other than HTTP requests in controller
> > Parallel son. Do not put another controller (Simple, If, Loop, etc.) as
> > child of PC?
> I agree with limitation, only accept HttpSamplerBase
> > Within the parameters of Parallel Controller, add the ability to schedule
> > requests children (choice of sequencing, selection of the thread executing
> > unit, etc..)
> If they are parallel why control sequencing ?

Because, sometimes I suppose we need to control the sequencing, for example, to make sure that a long request start first on the first Thread (of pool).
Or if there are some differences in browsers's behaviors for execute xmlhttpresquest
Comment 6 Milamber 2012-05-02 06:49:30 UTC
(In reply to comment #4)

> 
> The main goal being to simulate today browser behaviour with Ajax.

In my head, the parallel requests launch by a browser (at the same time) are *independent*.

Not wait for input form another parallel request (in child of same PC), cookies are the clone of the state of cookies from the PC, update cookie are possible at the end of PC.

We can execute preprocessor on all children of a PC before the start of parallel execution (if this possible)

Postprocessor run on the PC response data which are a concatenate of all response data from their child.
Example of PC response data:
=== Start of Child1 ===
###Headers###
Date: fdsqfdsfdsfdsq
Content-type: etc...
###Body###
ffdsqfdsqfdsfdsfdsqfd
sqfdsqfdsfdsfds
=== End of Child1===
=== Start of Child2 ===
###Headers###
Date: fdsqfdsfdsfdsq
Content-type: etc...
###Body###
ffdsqfdsqfdsfdsfdsqfd
sqfdsqfdsfdsfds
=== End of Child2===
etc
Comment 7 Sebb 2012-05-02 17:06:56 UTC
(In reply to comment #4)
> Hello,
> On my side this feature should allow:
> Parallel exécution of http sampler (or any sampler)

JMeter already provides parallel sampler execution in different threads.

I don't see any use case for any further parallelism except for Ajax.

> Exécution of assertions, pré-post processors

Seems to me the pre-processors should only apply to the main request.

As to assertions and post-processors, what are the use cases for these?
I'm not saying that there aren't any, but we should be wary of proceeding with the changes - which are likely to be very disruptive - with a very clear understanding of how they are designed to be used.

Again, without a clear purpose for the changes, it's going to be very difficult to design suitabl tests.

> The main goal being to simulate today browser behaviour with Ajax.
> But not simulate full browser ( no Javascript, CSS )
> 
> Regards 
> Philippe
Comment 8 Philippe Mouawad 2012-05-02 20:07:39 UTC
(In reply to comment #7)
> (In reply to comment #4)
> > Hello,
> > On my side this feature should allow:
> > Parallel exécution of http sampler (or any sampler)
> 
> JMeter already provides parallel sampler execution in different threads.
> 
I thought about JMS, but I agree it's not high priority
> I don't see any use case for any further parallelism except for Ajax.
> 
> > Exécution of assertions, pré-post processors
> 
> Seems to me the pre-processors should only apply to the main request.
> 
In a recent campaign I made using GWT RPC (I didn't have parallel feature yet), I faced the following case:
- Parent page has 8 Ajax Requests
- To sampler next main (what would be parent) request I had to extract from 1st and 6th information to inject in next sampler. GWT RPC has a format that need to be decoded.

If we make only parent execute Post Processor, then to implement this, I would have to split parent sampler and try to find the 2 samplers that I need to extract information. As I have no guarantee on execution order it will be very hard to do no ?
While if Post Processor applies to each child, it will be much easier to extract data.
The same applies I think for assertions, it would be much easier to find the failing sample.



> As to assertions and post-processors, what are the use cases for these?
> I'm not saying that there aren't any, but we should be wary of proceeding
> with the changes - which are likely to be very disruptive - with a very
> clear understanding of how they are designed to be used.
> 
> Again, without a clear purpose for the changes, it's going to be very
> difficult to design suitabl tests.
> 
> > The main goal being to simulate today browser behaviour with Ajax.
> > But not simulate full browser ( no Javascript, CSS )
> > 
> > Regards 
> > Philippe
Comment 9 Philippe Mouawad 2013-01-04 21:40:52 UTC
*** Bug 41293 has been marked as a duplicate of this bug. ***
Comment 10 Manjunath 2014-12-08 23:54:01 UTC
There are methods in HP loadrunner to do this, for example methods like "web_concurrent_Start" and "web_concurrent_end."

So whatever http requests you place within the web_concurrent_start/end methods, all those http requests will be executed at the same exact time even to the millisecond and the completion/end time  to complete the requests is based on the application responsiveness.
So the timing to be calculated for this is by taking the request which took the longest time in the set of requests, if you sum up the numbers it would be wrong, because this fails the idea of concurrency. 

If there are 3 requests executed concurrently and the server responds to the first two requests within the same time and third one took a second longer, then the time to be taken is the third requests time and not the sum of all three requests.


It would be great to see this feature come in soon.

with regards,
Manjunath
Comment 11 mchassagneux 2015-11-13 10:29:11 UTC
Any news about this features ? 
Nowaday, so many website use AJAX request executed in parallel, this controler is an awesome solution to test this page.
Comment 12 Akshay 2016-03-25 19:47:18 UTC
Hello JMeter Team,
Any idea on this feature, this will really avoid lot of redundancy in script, currently we are doing it with workaround but if we get controller it will be easy.
Comment 13 Philippe Mouawad 2016-04-19 20:44:20 UTC
*** Bug 59352 has been marked as a duplicate of this bug. ***
Comment 14 Patric Rufflar 2016-05-02 15:19:47 UTC
Will JMeter 3.0 finally contain this feature?
Comment 15 Rafal 2017-02-24 14:47:37 UTC
Please indicate the approximate date od 'Parallel controler'. Please.
Comment 16 UbikLoadPack support 2017-02-24 21:15:42 UTC
(In reply to Rafal from comment #15)
> Please indicate the approximate date od 'Parallel controler'. Please.

Hello Rafal,
There is no such concept on Apache OSS project.
Our project is mainly driven by volunteers work and external contributions.
You're welcome to contribute such piece of work.

For now, it's not a priority in our roadmap.

Regards