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. 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. Regards, Havard -- --->Google Switzerland GmbH Identifikationsnummer: CH-020.4.028.116-1<----
