LoadRunner has an option to wrap a series of calls in a couple of functions (web_concurrent_start & web_concurrent_end) that then causes the contained calls to be executed concurrently. It only applies in URL mode (where individual requests are separated) not in HTML mode (where this behaviour is implicit).
I'm not aware of how LR implements this, how many threads it uses in the pool, but I guess you have to have a maximum defined and I think this is fixed which is not perfect because different browsers use different values - if jmeter had a controller to do this then the ideal would be to have an option to specify the size of the pool. Assuming LR does not allow this value to be specified then if JMeter offered this ability then it would actually be a step up on LR. 2.6 allows something very similar for embedded resources; maybe this code be re-used to make a new controller? A bit like: HTTP Sampler - normal1 CONCURRENT_CONTROLLER [Option value of 4 for thread pool] ---- HTTP Sampler - ajax1 ---- HTTP Sampler - ajax2 ---- HTTP Sampler - ajax3 ---- HTTP Sampler - ajax4 ---- HTTP Sampler - ajax5 HTTP Sampler - normal2 On 23 Apr 2012, at 11:12, Philippe Mouawad wrote: > Hello, > In my opinion Ajax requests introduces at least 2 issues: > > - The request ordering (you cannot say I think in which order each > simultaneous request of the page will be executed), so this needs to be > scripted by some random mechanism > - Parallel requests BUT for the same data, this is not simulated by the > load, suppose for example the Tested application has some locks on parallel > requests for on set of Data ? > > > A controller for first part would be simpler to implement , it would play > the contents in a random order. > But ideally there should be some Controller implementation that runs its > children in Parallel and waits for the result, but it needs important > design and dev work I think. > > I am not sure other Load Test tools handle this completely and accurately > without limitations but would be interested to know if I am wrong. > > Regards > Philippe M. > http://www.ubik-ingenierie.com > > > On Mon, Apr 23, 2012 at 11:37 AM, Shmuel Krakower <[email protected]>wrote: > >> Hi, >> Yes, you are right, this is exactly what will happen in your case, the >> transaction controller will sum up all of the samplers response times, >> which doesn't reflect the browser behavior (as on browser it will run them >> in parallel). >> >> 1. I usually separate each Ajax call, although these Ajax calls are part of >> the page rendering, I believe each should be monitored by itself, this >> allowing you to say if you have performance problem with one of them. It is >> less important to load the system with these requests in parallel per each >> user, as you will end up load testing the system with more than one user, >> thus these Ajax calls will be executed in parallel during a load test >> anyway. >> 2. I really think some kind of parallel controller can be useful for these >> type of cases, to make them more close to reality. What do others think of >> this? >> >> Shmuel. >> >> >> On Mon, Apr 23, 2012 at 10:42 AM, venkatakurathi < >> [email protected]> wrote: >> >>> yes....i need to simulate those requets by same thread/user.because in my >>> transaction once a servlet is been called ,the above mentioned 4 >>> asynchronous calls been made to application in parallel.but when we >>> simulate >>> it through jmeter those calls are processed one by one(correct me if i am >>> wrong),which increases the response time of overall transaction.to know >>> the >>> accurate response time for the transaction ,i need to simulate all the 4 >>> asynchronous calls to be made to application at a time.... >>> and please also let me know how jmeter calculates the response times? >>> is it going to add all the loadtimes for samplers in a transaction? >>> >>> -- >>> View this message in context: >>> >> http://jmeter.512774.n5.nabble.com/how-to-simulate-asynchronous-calls-tp5653677p5658566.html >>> Sent from the JMeter - User mailing list archive at Nabble.com. >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> > > > > -- > Cordialement. > Philippe Mouawad. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
