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/Pr
On 20 January 2012 17:00, Havard Blok 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 o
On 20 January 2012 18:26, sebb 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. However, I think you're
On 24 January 2012 16:11, Havard Blok wrote:
> On 20 January 2012 18:26, sebb 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 call
On 24 January 2012 20:21, sebb wrote:
>
> 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
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
