jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From chaitanya bhatt <bhatt.chaita...@gmail.com>
Subject Re: Many slaves or many threads?
Date Wed, 21 Jul 2010 09:39:58 GMT
Good that you let us know you are using Virtual Machines as injectors. In a
normal scenario if utilization is below 80% I don't see anything which
should stop you from increasing the thread.

But there are few things which is very dangerous about "VIRTUAL MACHINES" in
load testing paradigm.
1. You may see negative transaction response time or at times you may see
incorrect transaction response time.
2. Virtual users technically runs slower than when on true phsyical
machine leading to ambiguous transaction response time(this is a little
subjective, but still very much true).

Virtual machines show up with these problems because every communication
between the virtual(slave) OS kernal and the host OS kernal happens through
a hyperviser( which is nothing but a software component). Even the slave
machine's system clock is synced up through the hypervisor. If there are too
many interrupts in the CPU or if the CPU is blocked in an IO operation, then
a clock drift can occur (de-sync of guest/slave OS's system clock), which
messes up your transaction response time.

So, for you question - more threads per virtual machine vs. more machines
with less threads,  the answer is "More guest machines with less threads is
safer in a Virtual Machine context." The reason to this is, if a clock drift
occurs in a guest machine, then it affects fewer threads. Plus, with more
requests coming from different slave/guest machines creates diverse load on
the CPU which reduces CPU queuing. I hope you got my point.

Between, apart from System Wide resource utilization, are you monitoring the
JVM heap as well? if not then I recommend you to do it. Use JConsole and
monitor the JVM heap. Ensure that new gen and tenured gen areas of the jvm
heap are not choking. If you see thread thrashing or any abnormal behavior
inside the heap then you might have to re-configure the heap before loading
up additional threads.

 -Chaitanya M Bhatt
http://www.performancecompetence.com <http://www.performan/>

2010/7/21 Jörg Godau <J.Godau@schuetze-berlin.de>

> 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:raginit@cybage.com]
> > 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:bhatt.chaitanya@gmail.com]
> > 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 <J.Godau@schuetze-berlin.de>
> >
> > > 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: jmeter-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
> > >
> > >
> >
> > "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: jmeter-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message