jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Havard Blok <>
Subject runTest: synchronous vs. asynchronous
Date Fri, 20 Jan 2012 17:00:59 GMT
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 ( 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.


--->Google Switzerland GmbH Identifikationsnummer: CH-<----

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message