On 24 January 2012 16:11, Havard Blok <hrb...@google.com> wrote: > On 20 January 2012 18:26, sebb <seb...@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<----
