jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <philippe.moua...@gmail.com>
Subject Re: On-demand thread creation
Date Sat, 25 Apr 2015 06:58:05 GMT
Hi Vladimir,
For now I don't see why Sn approach you described would not work but I may
not have the whole picture.

I don't see why it could not be integrated in JMeter as it seems to be a
not too edgy use case.

Feel free to contribute a patch or PR on github for easier feedback on your
code.

Regards
Philippe

On Friday, April 24, 2015, Vladimir Sitnikov <sitnikov.vladimir@gmail.com>
wrote:

> Hi,
>
>
> I want JMeter to create threads only when it is required for the next
> iteration.
>
> Currently JMeter has only two options:
>
> O1) pre-create all threads at startup -- not an option really due to
> OOM and due to the fact it cannot provision new threads on failures.
> O2) create threads with given delays (ramp up with fixed delays). Does
> not work for me (see below). Ramp up may lag behind the need of
> threads (for instance, if threads fail faster than created in
> ramp-up). Ramp up may create excessive threads if threads existing
> operate fast enough to drive the load.
>
> I want something like the following:
>
> S1) A certain timer/test plan element is marked as <<start of test>>. It
> must have a timer that shapes the load.
> S2) Thread group creates threads only in case there is not enough
> threads waiting _at_ <<start of test>> element. In other words, TG would
> stop creating new threads if certain number of threads become waiting
> on the shaping timer. <<The number of prepared>> threads should probably
> be configurable.
> S3) <<Ramp up>> configuration,  would become irrelevant.
> S4) <<Number of threads>> configuration would become <<maximum number
of
> active threads>> and <<target number of prepared threads at start of
> test element>> settings. For instance, TG would automatically spawn
> threads if they die.
> S5) The proposed solution works for both looping and non-looping scenarios
>
> I understand, it might be too intimate cooperation of TG and test plan
> elements, however it is the simplest approach I see to explain what I
> want.
>
> Do you think this can be integrated into JMeter?
>
> I think it is good to decouple thread group and shaping timer,
> otherwise the number of combinations would explode.
>
> I cannot use existing solutions due to:
>
> P1) JMeter OOB does not have <<on demand thread creation>>
> P2) UltimateThreadGroup (from jmeter plugins) cannot be used to shape
> the load since the number of required threads is not known in advance.
> UTG cannot create realistic workloads (poisson workloads)
> P3) Current timers (both in-core and out-of core) cannot prevent
> creating of new threads
>
> The closest workaround I see is calling "stop thread" from within a timer.
> For instance, a timer might stop thread instead of issuing a delay in
> case the delay would be "too big".
> The idea is "if thread should be delayed much, then TG would anyway
> create a new thread soon, so we kill current one and hope a new one
> would arrive later".
> It does not look nice since TG would have to spawn threads.
>
> Background.
>
>
> My test plan has <<shaping timer>> in the beginning to make sure the
> overall load is kept constant.
> So, if too many threads are created, they just wait.
>
>
> For instance, if I want to test 60 orders/hour and and it takes ~30
> seconds to create an order, I specify: 120 threads, ramp up=15seconds
> and enable <<delayed thread creation>>.
> This saves a bit of memory since JMeter does not create all the threads
> upfront.
>
> However, particular test executions might stall for certain reasons,
> so I have to be conservative on the <<maximum>> number of threads.
>
> I do not want to test <<each order at 0, 60, 120, 180 sec>> pattern, so
> my shaping timer issues fuzzy delays (~poisson process in fact).
> For instance, a <<60 orders/hour>> pattern could be <<0, 15, 150, 180>>.
>
> So far, so good.
>
> Unfortunately, ramp up approach fails for durability testing and high
> throughput tests.
>
> In durability testing, the number of threads is not known in advance:
> threads might fail, so I have to setup something like 100'000 threads,
> ramp up 7 days, then at the end of the test this fails with OOM.
>
> In high-throughput tests (>1/sec), <<per thread ramp up delay>> have to
> be small, otherwise I would lack enough threads to drive the desired
> load.
> On the other hand, too little ramp up value could result in too many
> waiting threads, thus memory issues.
>
> --
> Regards,
> Vladimir Sitnikov
>


-- 
Cordialement.
Philippe Mouawad.

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