Hello, thank you for your replies.
The problem is we use one large machine with multiple Virtual Machines on it - so there is a total limit to the cpu and memory. More slaves means more overhead in terms of the machine setup. All things being equal (less than 80% utilisation) is it better to have more threads or more slaves? Will jmeter produce similar results when running 10 threads on 1 slave and 1 thread on 10 slaves? Mit freundlichen Grüßen Jörg Godau SCHÜTZE Consulting Informationssysteme GmbH Argentinische Allee 22b 14163 Berlin Tel.: 030/ 802 49 44 Fax: 030/ 8090 39 95 www.schuetze-berlin.de Geschäftsführer: Klaus-Dieter Schütze Registergericht: Amtsgericht Charlottenburg Registernummer: HRB 73618 Umsatzsteuer-Identifikationsnummer gemäß § 27a Umsatzsteuergesetz: DE 813181239 > -----Ursprüngliche Nachricht----- > Von: Ragini Thakur [mailto:[email protected]] > Gesendet: Mittwoch, 21. Juli 2010 10:42 > An: JMeter Users List > Betreff: RE: Many slaves or many threads? > > I agree with Chaitanya. You can monitor the CPU and memory utilization > of slave machines and based on that may decide to add more threads or > more slaves in the setup. > > Regards, > Ragini Thakur > > > -----Original Message----- > From: chaitanya bhatt [mailto:[email protected]] > Sent: Wednesday, July 21, 2010 2:07 PM > To: JMeter Users List > Subject: Re: Many slaves or many threads? > > Jörg, > > It depends on the hardware configuration of the injector machines. 100 > threads is perfectly sensible if your injector machine is a quad-core > machine with at least 2-3 gigs of ram. But if you have a low > configuration > machine then even 100 threads might be too taxing for it. > > The key to find out what is sensible load on the injector and what is > not is > by monitoring the injector machine first -- to see if something is > crossing > the 80% utilization watermark in the resource front. If yes then > reduce the > threads and introduce more slaves, if no then increase the threads. > -Chaitanya M Bhatt > 2010/7/21 Jörg Godau <[email protected]> > > > Hello All, > > > > we are trying to configure our testing environment in an optimal > fashion. > > > > We would like to have 100 or more parallel threads hitting our > application > > server. > > > > At the moment we are using 10 jmeter-slaves each running 10 threads > (each > > slave runs in a virtual machine). > > > > Is this a sensible setup? > > > > Would we be better off running 1 jmeter-slave with 100 threads? > > > > Or 5 slaves with 20 threads? > > > > Or something else? > > > > How does everyone else setup tests that use many threads/processes? > > > > > > Mit freundlichen Grüßen > > Jörg Godau > > > > SCHÜTZE Consulting Informationssysteme GmbH Argentinische Allee 22b > > 14163 Berlin > > Tel.: 030/ 802 49 44 > > Fax: 030/ 8090 39 95 > > www.schuetze-berlin.de > > > > Geschäftsführer: Klaus-Dieter Schütze > > Registergericht: Amtsgericht Charlottenburg > > Registernummer: HRB 73618 > > Umsatzsteuer-Identifikationsnummer gemäß § 27a Umsatzsteuergesetz: DE > > 813181239 > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > "Legal Disclaimer: This electronic message and all contents contain > information from Cybage Software Private Limited which may be > privileged, confidential, or otherwise protected from disclosure. The > information is intended to be for the addressee(s) only. If you are not > an addressee, any disclosure, copy, distribution, or use of the > contents of this message is strictly prohibited. If you have received > this electronic message in error please notify the sender by reply e- > mail to and destroy the original message and all copies. Cybage has > taken every reasonable precaution to minimize the risk of malicious > content in the mail, but is not liable for any damage you may sustain > as a result of any malicious content in this e-mail. You should carry > out your own malicious content checks before opening the e-mail or > attachment." > www.cybage.com > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
