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" <[email protected]>: > On 24 January 2012 16:11, Havard Blok <[email protected]> wrote: > > On 20 January 2012 18:26, sebb <[email protected]> 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<---- >
