Mailing-List: contact dev-help@jmeter.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jmeter.apache.org
Received-SPF: pass (athena.apache.org: domain of philippe.mouawad@gmail.com
 designates 209.85.161.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAOGo0VYLN48nHiG_qbYTBmk2wvnfVapj=HDPM8EYGEdy2DzA-A@mail.gmail.com>
References: 
 <CAOGo0VZFKGKGu_VS2RqinWW0ZC+XSYDc4y3_Qj_nKqE8wq8iuw@mail.gmail.com>
	<CAOGo0VY1P-jO0+zUMSaWZZCDt9B_kvVFkh_4Cbb8H-tHvMi=Gw@mail.gmail.com>
	<502A1FB2.30501@apache.org>
	<CAH9fUpYndtSCcKdbdzFakL1=aSFFSOFQDBaA9RaEdMFUUZN0tw@mail.gmail.com>
	<CAOGo0VYLN48nHiG_qbYTBmk2wvnfVapj=HDPM8EYGEdy2DzA-A@mail.gmail.com>
Date: Tue, 14 Aug 2012 14:39:41 +0200
Message-ID: 
 <CAH9fUpaQz9KnOEb=buQ8UW-f+PjWx+eX2-iG_2v0PumXU_i2pw@mail.gmail.com>
Subject: Re: OnDemandThreadGroup => Delay startup option on standard
 ThreadGroup
From: Philippe Mouawad <philippe.mouawad@gmail.com>
To: "dev@jmeter.apache.org" <dev@jmeter.apache.org>
Content-Type: multipart/alternative; boundary=e89a8fb1ef18b5398404c7391a46

--e89a8fb1ef18b5398404c7391a46
Content-Type: text/plain; charset=ISO-8859-1

Hello,
I think the next step should be to pool threads for start later as tests
show clearly that live threads are below the max threads.

Sebb , milamber did you measure thread creation overhead ?

Thanks
Regards
Philippe
On Tuesday, August 14, 2012, sebb wrote:

> On 14 August 2012 11:21, Philippe Mouawad <philippe.mouawad@gmail.com<javascript:;>>
> wrote:
> > Hello,
> > That was its intention :)
> >
> > Great news, thanks sebb for reworking it (although i liked it as it was
> ;)
> > ).
> > And thanks both for tests.
> >
> > Maybe we should send a note on the changes to the original user mailing
> > list message as kirk p started some tests, no ?
>
> Yes, when I've finished the changes.
>
> > Regards
> > Philippe
> >
> >
> > On Tuesday, August 14, 2012, Milamber wrote:
> >
> >>
> >>
> >> Le 13/08/2012 18:58, sebb a ecrit :
> >>
> >>> On 13 August 2012 17:07, sebb<sebbaz@gmail.com <javascript:;>>  wrote:
> >>>
> >>>> I've made the changes to merge the OnDemand code back into the
> >>>> standard ThreadGroup.
> >>>>
> >>>> This means it's now trivial for users to switch between the different
> >>>> startup types.
> >>>>
> >>>> I hope I've not broken anything ...
> >>>>
> >>> Seems to work OK with a simple test plan of a single Java sampler, 10
> >>> loops.
> >>> Setting the ramp-up to the same as the thread count gives me a max of
> >>> 3 threads concurrently.
> >>>
> >>> This runs out of memory when run without delayed start and 10000
> threads.
> >>> The same test starts fine and runs for a while with delayed start.
> >>>
> >>
> >> I've run a simple test of 2 Java sampler (with 1s sleep time), 10 loops,
> >> with 120000 threads and ramp-up 6000s with jmeter-trunk (on Linux 64
> bits
> >> server with 48 cores, sun jdk 6 64bits)
> >>
> >> ===
> >> With delayed start, test works fine.
> >> 2400004 of sampler results
> >>
> >> Max heap size during tests: ~2.6 GB
> >> (jmeter java opts : HEAP="-Xms8g -Xmx8g -XX:+UseConcMarkSweepGC
> >> -Xloggc:/tmp/gclog_`date '+20%y%m%d%H%M%S'`.txt")
> >>
> >> Average number of LWP (Light-weight process): ~500  (~threads inside the
> >> java process via the linux command 'ps')
> >>
> >> ===
> >> Without delayed start: OutOfMemoryError: unable to create new native
> >> thread.
> >> 45176 of sampler results (test not ended, kill by me after the OOME
> >> notification)
> >>
> >> Max heap size during tests: ~2.3 GB
> >> (jmeter java opts : HEAP="-Xms8g -Xmx8g -XX:+UseConcMarkSweepGC
> >> -Xloggc:/tmp/gclog_`date '+20%y%m%d%H%M%S'`.txt")
> >>
> >> Max number of LWP (Light-weight process): 30396  (~threads inside the
> java
> >> process)
> >>
> >> ===
> >>
> >> Conclusion IMHO: A great behavior for JMeter and tests with a huge
> number
> >> of threads (users) with small number of individual loops per user, like
> >> webservice's test
> >>
> >> Milamber
> >>
> >>  It's much quicker to stop the test as well.
> >>>
> >>> I was able to start a test with 50000 threads, but after that memory
> >>> was a problem.
> >>> Also, the test takes quite a long time to start up, presumably because
> >>> of the array of JMeterThread instances.
> >>>
> >>>  There's probably still some tidying up that could be done.
> >>>>
> >>>> For example, StandardJMeterEngine still creates the JMeterThread
> >>>> instances at the start. It might be better to make the thread group
> >>>> class responsible for handling these, so the additional objects are
> >>>> not created until needed.
> >>>>
> >>> I think that's what broke my tests with more than about 60000 threads.
> >>>
> >>> As well as deferring creation of these objects,they need to be
> >>> released once the thread has completed.
> >>>
> >>>  BTW, my French is not up to translating the delayed_start property
> >>>> entry - please can someone else fix that so the tests no longer fail?
> >>>> Thanks!
> >>>>
> >>>
> >>
> >
> > --
> > Cordialement.
> > Philippe Mouawad.
>


-- 
Cordialement.
Philippe Mouawad.

--e89a8fb1ef18b5398404c7391a46--