jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From da...@davidwbrown.name
Subject Re: Scalability of JMeter
Date Wed, 11 Mar 2009 16:38:00 GMT
Hello, simply put: WOW! I am archiving this for my client doubters when I talk to them about
testing their systems with JMeter. I'm sure this must be a real kudos to the JMeter dev.

Regards, David.

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


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