Hi, Introducing this is not easy as there is currently an assumption on code that TestElement are cloned per thread/User. If you look at code of concurrent download you can grasp part of the complexity. But of course if you feel like implementing this, it would be great :-)
Thinking further about this, I tend to think that parallelism may not be the issue here but more the "non random" order of calls, what's your thoughts on this ? Regards Philippe M. On Fri, Jan 15, 2016 at 1:48 PM, Vladimir Sitnikov < [email protected]> wrote: > Hi, > > Modern http pages often result in patterns like "1 request for > page.html, then 5 more requests for data". > Currently test plans have to resort to sequential execution of "ajax > samplers". > > Are there plans for enabling concurrent samplers within a single JMeter > thread? > For instance, something like "Concurrent controller" that will execute > children samplers concurrently. > > Note: I am aware of "use concurrent pool" for "embedded resources > download", however I need concurrent execution of http samplers, not > the embedded resources. I need to configure "url, params, keepalive, > etc". > Note: ThreadGroup does not help me either, as I need to test > concurrent requests for the same "user_id". Generally speaking, each > JMeter thread should use its own user id (its own cookie, etc), > however when launching "5 concurrent ajax requests", they all should > use the same cookie info. Different virtual user (i.e. JMeter thread) > should use its own pack of requests. > > PS. I'm aware of jmeter-plugins' Inter-Thread Communication, however, > using JP IPC for fetching a couple of ajax requests seems to be an > overkill. > > -- > Regards, > Vladimir Sitnikov > -- Cordialement. Philippe Mouawad.
