jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shmuel Krakower <shmul...@gmail.com>
Subject Re: runTest: synchronous vs. asynchronous
Date Fri, 03 Feb 2012 22:15:21 GMT
I get Havard point. He asks for something simillar to what's HP Load Runner
has, to promise constant throuput no matter how much threads / virtual
users he set and what the SUT state is (I.e. responding very slow).

On the other hand having async samplers might be a problem when you need to
parse a response and use it on the next request, as the next sampler may
run before the post-processor of the current sampler gets executed.

I haven't used yet the constant throughput shaping timer but from the
discussions on this list it sounds like it does the trick.
בתאריך 2012 1 24 21:22, מאת "sebb" <sebbaz@gmail.com>:

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message