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: [email protected] > > . > > 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: [email protected] For additional commands, e-mail: [email protected]
