jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ian Blavins" <iblav...@temenos.com>
Subject RE: Scalability of JMeter
Date Thu, 12 Mar 2009 08:15:03 GMT
G'day

See below

Ian Blavins
Software performance specialist
.
TEMENOS
The Banking Software Company
.
PeopleBuilding 2, Maylands Av
Hemel Hempstead   UK   HP2 4NW
.
T:  +44 (0) 1442 431 106
E:  iblavins@temenos.com
.
www.temenos.com
.

-----Original Message-----
From: sebb [mailto:sebbaz@gmail.com] 
Sent: Wednesday, 11 March 2009 10:48 PM
To: JMeter Users List
Subject: Re: Scalability of JMeter

On 11/03/2009, Ian Blavins <iblavins@temenos.com> wrote:
> G'day
>
>
>
>  This forum is mostly requests for help and responses thereto.
>  Occasionally there is a report on JMeter usage. This is one of those.
>

Thanks very much - this is very useful.

>
>
>
>  Last weekend we ran JMeter, wrapped by some locally developed
>  infrastructure, against a stub server. The intent was to determine the
>  throughput of JMeter supported by our infrastructure.
>
>
>
>  Our infrastructure provides run time data in real time, or ahead of
>  time, and collects sampler response times from the samplers in real
>  time. Both of these are done over the network.
>
>
>
>  In the run we delivered SOAP requests, with run time data substituted,
>  to our stub server and received, timed, validated, and emitted timings
>  for the stub's responses.
>
>
>
>  Running 5 JMeter servers on a 16 CPU IBM p570 server with twin core

When you say servers, were you running in client-server mode, or GUI
or non-GUI standalone?

INB> I used the GUI to initiate the run on remote JMeter servers. I reduced the communication
back from the samplers to the GUI with remote batching mode set to (infrequent) sampling.
After starting the run the GUI really played no further part.

>  Power 5 1.6GHz CPUs and lots of memory we were able to sustain an
>  average of 5,350 SOAP requests per second for the 49 minute core of the
>  run. We were able to deploy 92% of the available CPU capacity. We used 6
>  PCs to run our infrastructure in support. There were no singleton
>  resources in the test and the p570 and 6 PCs represents a scalability
>  unit that can be replicated essentially arbitrarily.
>
>
>
>  The sampler was a locally written SOAP sampler implemented on the Java
>  request sampler.
>

Is this because the existing SOAP samplers did not have the required
functionality, or because they did not perform? I know the
Webservice(SOAP) sampler is rather CPU intensive, but the XML-RPC one
should be OK.

INB> Our functionality requirements were heavy and I wouldn't have expected a standard
sampler to have met them.

Did you use a 3rd party SOAP library or just HTTP?

INB> We wrote our own code to read pre-captured SOAP messages from a file, provide them
with run time data, and wrap an appropriate HTTP envelope around them. The code validates
that the reply is a reply to the SOAP message sent. But the heavy part is interfacing to network
based run time data servers and response time capturers.

>
>  The test plan was a locally developed standardized test plan. It
>  dynamically detects the number and location of SOAP requests comprising
>  one or more business transactions identified in the test plan. It sends
>  those SOAP requests in order, business transaction by business
>  transaction, customizing with run time data received over the network as
>  it goes. Much of the test plan is incorporated in include modules. The
>  intent is to have a single test plan that will run essentially any test
>  so reducing proliferation and maintenance.
>
>
>
>  We tuned the standardized test plan to eliminate JMeter test plan
>  components that we found to be expensive, most notably anything that
>  uses a JavaScript interpreter.

Yes, that would likely be expensive as it has to be instantiated each time.

>
>  This e-mail isn't supposed to start some competition to see who can run
>  JMeter fastest. It is simply to recognize the performance available with
>  JMeter and the flexibility of its architecture to allow adaptation to
>  specific needs. My congratulations to those who contributed to its
>  development.
>
>

Thanks again for the very useful feedback.

>
>
>
>
>
>
>  Ian Blavins
>  Software performance specialist
>
>  .
>
>  TEMENOS
>  The Banking Software Company
>
>  .
>
>  PeopleBuilding 2, Maylands Av
>
>  Hemel Hempstead   UK   HP2 4NW
>
>  .
>
>  T:  +44 (0) 1442 431 106
>  E:  iblavins@temenos.com
>
>  .
>
>  www.temenos.com <http://www.temenos.com>
>
>  .
>
>
>
>
>  Disclaimer:
>  If you have received this e-mail in error please notify the sender.
>  Please note that any views or opinions presented in this e-mail are solely
>  those of the author and do not necessarily represent those of TEMENOS.
>  We recommend that you check this e-mail and any attachments against viruses.
>  TEMENOS accepts no liability for any damage caused by any malicious code
>  or virus transmitted by this e-mail.
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org

Disclaimer:
If you have received this e-mail in error please notify the sender. 
Please note that any views or opinions presented in this e-mail are solely 
those of the author and do not necessarily represent those of TEMENOS. 
We recommend that you check this e-mail and any attachments against viruses. 
TEMENOS accepts no liability for any damage caused by any malicious code 
or virus transmitted by this e-mail.


---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org


Mime
View raw message