jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: runTest: synchronous vs. asynchronous
Date Tue, 24 Jan 2012 19:21:51 GMT
On 24 January 2012 16:11, Havard Blok <hrblok@google.com> wrote:
> On 20 January 2012 18:26, sebb <sebbaz@gmail.com> wrote:
>
>>
>> You can certainly make runTest() return without waiting for the SUT.
>> But how do you handle the responses?
>>
>
> I guess the caller of runTest() would have to have its own thread pool, and
> issue calls to satisfy the desired QPS rate.

Effectively that is just increasing the total number of threads.
And, unless the thread pool is infinitely expandable, the same problem
may still occur.

Note also that although the sampler thread is doing nothing whilst
waiting for a reply,
at some point there will have to be a thread that waits for the
response to be returned.
One might be able to use a single thread to wait for multiple
responses - e.g. using polling or asynchronous I/O - but there has to
be at least one thread to allow the response(s) to be processed.

Much simpler just to start with some spare threads.

> However, I think you're
> comment below shows that JMeter is not designed to do this, neither are
> there any plans to change. Which is fine, and all I was looking for really.
>
>
>> JMeter was originally designed for testing synchronous protocols.
>> Samplers etc. are designed assuming they are single-threaded and use
>> thread-local data.
>>
>> I suspect it would need a complete redesign to handle asynchronous
>> protocols fully. We had a lot of issues trying to implement parallel
>> download of
>> embedded resources in HTTP samplers.
>>
>
>
> Regards,
> Havard
>
>
> --
> --->Google Switzerland GmbH Identifikationsnummer: CH-020.4.028.116-1<----

Mime
View raw message