You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@jmeter.apache.org by bu...@apache.org on 2012/04/28 16:52:46 UTC
[Bug 53159] New: Enable parallel execution of Sampler for Same user
to simulate Ajax Requests
https://issues.apache.org/bugzilla/show_bug.cgi?id=53159
Priority: P2
Bug ID: 53159
Assignee: issues@jmeter.apache.org
Summary: Enable parallel execution of Sampler for Same user to
simulate Ajax Requests
Severity: enhancement
Classification: Unclassified
OS: All
Reporter: p.mouawad@ubik-ingenierie.com
Hardware: All
Status: NEW
Version: 2.6
Component: Main
Product: JMeter
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)
- ...
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 53159] Enable parallel execution of Sampler for Same user to
simulate Ajax Requests
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53159
--- Comment #4 from Philippe Mouawad <p....@ubik-ingenierie.com> ---
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
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 53159] Enable parallel execution of Sampler for Same user to
simulate Ajax Requests
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53159
--- Comment #5 from Milamber <mi...@apache.org> ---
(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
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 53159] Enable parallel execution of Sampler for Same user to
simulate Ajax Requests
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53159
--- Comment #10 from Manjunath <ma...@yahoo.com> ---
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
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 53159] Enable parallel execution of Sampler for Same user to
simulate Ajax Requests
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53159
--- Comment #1 from Milamber <mi...@apache.org> ---
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..)
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 53159] Enable parallel execution of Sampler for Same user to
simulate Ajax Requests
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53159
--- Comment #6 from Milamber <mi...@apache.org> ---
(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
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 53159] Enable parallel execution of Sampler for Same user to
simulate Ajax Requests
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53159
--- Comment #8 from Philippe Mouawad <p....@ubik-ingenierie.com> ---
(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
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 53159] Enable parallel execution of Sampler for Same user to
simulate Ajax Requests
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53159
Philippe Mouawad <p....@ubik-ingenierie.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |sonam.chauhan@ce.com.au
--- Comment #9 from Philippe Mouawad <p....@ubik-ingenierie.com> ---
*** Bug 41293 has been marked as a duplicate of this bug. ***
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 53159] Enable parallel execution of Sampler for Same user to
simulate Ajax Requests
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53159
Philippe Mouawad <p....@ubik-ingenierie.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P2 |P1
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 53159] Enable parallel execution of Sampler for Same user to
simulate Ajax Requests
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53159
--- Comment #7 from Sebb <se...@apache.org> ---
(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
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 53159] Enable parallel execution of Sampler for Same user to
simulate Ajax Requests
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53159
--- Comment #3 from Sebb <se...@apache.org> ---
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.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 53159] Enable parallel execution of Sampler for Same user to
simulate Ajax Requests
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53159
Philippe Mouawad <p....@ubik-ingenierie.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |p.mouawad@ubik-ingenierie.c
| |om
--- Comment #2 from Philippe Mouawad <p....@ubik-ingenierie.com> ---
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 ?
--
You are receiving this mail because:
You are the assignee for the bug.