On 20 January 2012 17:00, Havard Blok <[email protected]> wrote: > A common use case of JMeter within Google is to implement a custom sampler, > sub-classed from AbstractJavaSamplerClient, and handle the requests > relevant to the load test in the runTest() method (from JavaSamplerClient). > Typically, RPC requests over Protocol Buffers ( > http://en.wikipedia.org/wiki/Protocol_Buffers) are constructed within > runTest(), executed, and the latency measurements stored in SampleResult. > The custom sampler is included in an auto-generated test plan, which > includes a few externalized options like thread count, duration, etc. > > From JMeter's perspective, the call to runTest() is blocking, so to > generate higher load, we'll increase the thread count. So far, all good. > Until somebody asks for a specific QPS. In this case, we've used the > ConstantThroughputTimer, which delays threads to achieve an overall max > throughput. However, it might be that requests to the System Under Tests > hang or experience high latency, which means that the desired QPS will not > be reached. So you'll have to add more threads to achieve a constant QPS. > > This leads to the frequently asked question: Well, since all these threads > are just waiting for a server response anyway, why can't the runTest() be > asynchronous? The load generation machine itself is not busy, it's just > sitting there waiting for replies from the System Under Test.
You can certainly make runTest() return without waiting for the SUT. But how do you handle the responses? > I was hoping some of you might shed some light on this, and possibly point > to related discussions or design decisions. Or maybe we've used the wrong > JMeter configuration. It would be great to have some definite answers when > this comes up. 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<----
