jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ian Blavins" <iblav...@temenos.com>
Subject Scalability of JMeter
Date Wed, 11 Mar 2009 16:22:16 GMT
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.

 

 

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
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.

 

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.

 

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.

 

 

 

 

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.

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