Simulating browser-like concurrent download of http samplers

[Vladimir Sitnikov <si...@gmail.com>]

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

Re: Simulating browser-like concurrent download of http samplers

[Vladimir Sitnikov <si...@gmail.com>]

> Introducing this is not easy as there is currently an assumption on code
>that TestElement are cloned per thread/User

I know that. I know "controller processing" is super-obscure. Once I
even tried to follow the logic behind TransactionController, but I
gave up.

On the other hand, implementing a "concurrent controller" rather than
half-baked support for http samplers might look cleaner.

A great success would be if "concurrent resource download" could
leverage "concurrent controller" infrastructure.

The difficult part is the semantics.
Enabling concurrent writes to the "variables" would probably hurt.
Think of 2 concurrent requests each of those use javascript pre-post
processor.

Having a dedicated set of variables for each "sub-thread" (e.g.
copy-on-write) is good (they do not need to access each other's
variables after all), however it would require some "merge" operation
that will merge the results from the sub-threads and update "original
variables" accordingly.

The easiest way to merge is not doing that at all and require some
user-given action to "propagate information from sub-thread to the
original thread". <-- I'm sorry to braindump here. It looks like I'm
copy&pasting things from "actor model".

I'm not sure if that "memory model" was already thought through.

>But of course if you feel like implementing this, it would be great :-)

It is not the top priority for me, however the problem does exist, so
I want to test the ground if that is feasible, or if that contradicts
to the roadmap.

>the issue here but more the "non random" order of calls, what's your
>thoughts on this ?

Well, JMeter invokes samples in more or less the order in which they
were recorded.
It does not mean they always come in that order, but in my experience
the order of requests from browser is more or less predictable.
Even "concurrent" requests are launched by a single-threaded
javascript logic, thus the variance is not that high.

Vladimir

Re: Simulating browser-like concurrent download of http samplers

[Philippe Mouawad <ph...@gmail.com>]

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 <
sitnikov.vladimir@gmail.com> 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.