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: [email protected] . www.temenos.com . -----Original Message----- From: sebb [mailto:[email protected]] Sent: Wednesday, 11 March 2009 10:48 PM To: JMeter Users List Subject: Re: Scalability of JMeter 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? 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: [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] 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]
