On 11/03/2009, Ian Blavins <[email protected]> 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? > 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. Did you use a 3rd party SOAP library or just HTTP? > > 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: [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]
