jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Finch, Sam" <>
Subject RE: JMeter & Asynchronous Testing
Date Wed, 14 Apr 2004 07:09:21 GMT
The objective is to soak-test the system with n concurrent events.  As I
understand it you need one thread
per event (as the sampler would block).  This would mean n threads.  n could
be as much as 2000 given the current
testing scenarios.


-----Original Message-----
From: Michael Stover []
Sent: 13 April 2004 18:41
To: JMeter Users List
Subject: Re: JMeter & Asynchronous Testing

If you write your own JavaSamplerClient to block and wait for the event
response, why would that result in a huge number of threads?


On Tue, 2004-04-13 at 11:53, Finch, Sam wrote:
> Hi
> I am trying to use the Java sampler to load-test a class implementing an
> asynchronous messaging interface.
> The class has two methods:
>   /** Send  a message. */
>   send(String msg);
>   /** Add a listener for incoming messages returned in response. */
>   addListener(Listener l);
> send() returns instantly.  addListener() expects a listener object that
> contains an onEvent() callback following the usual pattern.  The class
> thread pooling internally.
> I need to test round-trip times for a variety of messages under different
> load conditions, with the following constraints:
>  - Every message will (eventually) receive a reply.
>  - The target system is expected to process several messages at a time.
>  - The target system makes no guarantee about the order of replies.
>  - Outgoing messages contain a sequence #, which is returned in the reply.
> Responsiveness is measured by the time elapsed between calling send() and
> being called by onEvent(), for requests and responses with the same
> number.
> So, how should I do this in JMeter?
> I am tempted to implement it by providing a simulated synchronous
> to a Java sampler.  The thread would appear to be IO blocked but in
> would send() the message and enter a wait state until notified by a
> thread that would trigger it with timing information when the reply came
> This pushes control back to JMeter.  I can use JMeter to control threads,
> randomise message types etc etc.  The downside is that it will result in a
> huge number of threads.  I expect to load test the server with up to 2000
> concurrent messages - which would mean a corresponding number of threads!
> Hopefully I am missing something.  My questions are:
>  - Has JMeter been designed to test an asynchronous interface?
>  - If not, can it be done without simulating a synchronous interface?
>  - If not, are there other frameworks that are better suited?
>  - If not, is there any interest in expanding JMeter so it can cater for
> this stuff natively?
> Thanks for any comment and insight.
> Sam
> CONFIDENTIAL: This e-mail, including its contents and attachments, if any,
are confidential. If you are not the named recipient please notify the
sender and immediately delete it. You may not disseminate, distribute, or
forward this e-mail message or disclose its contents to anybody else.
Copyright and any other intellectual property rights in its contents are the
sole property of eSpeed, Inc and its affiliates.
> This e-mail was issued by eSpeed International Limited ("eSpeed").  eSpeed
is a limited liability company incorporated under the laws of England
(company number 3809189 and VAT registration number 577 406809).  eSpeed's
registered office is at One America Square, London EC3N 2LS.  For any issues
arising from this email please reply to the sender.
> E-mail transmission cannot be guaranteed to be secure or error-free. The
sender therefore does not accept liability for any errors or omissions in
the contents of this message which arise as a result of e-mail transmission.
If verification is required please request a hard-copy version.
> Although we routinely screen for viruses, addressees should check this
e-mail and any attachments for viruses. We make no representation or
warranty as to the absence of viruses in this e-mail or any attachments.
Please note that to ensure regulatory compliance and for the protection of
our customers and business, we may monitor and read e-mails sent to and from
our server(s). 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
Michael Stover <>
Apache Software Foundation

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message