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) - ...
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..)
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 ?
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.
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
(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
(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
(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
(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
*** Bug 41293 has been marked as a duplicate of this bug. ***
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
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.
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.
*** Bug 59352 has been marked as a duplicate of this bug. ***
Will JMeter 3.0 finally contain this feature?
Please indicate the approximate date od 'Parallel controler'. Please.
(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
This issue has been migrated to GitHub: https://github.com/apache/jmeter/issues/2817