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: Avoid thread sleep on delays
Date Mon, 14 Oct 2019 08:19:05 GMT
Hello Vladimir,
This enhancement would be great, it is indeed needed, but it was not
attempted due to lack of time and possibly backward incompatibility for 3rd
party plugins.
Ideally we should if possible switch to Async IO in a next step, but what
you propose would be a clear improvement.

Regarding ThreadLocal, there are 2 uses of them:
- One just for performance
- One for what is in fact a UserSession. As a first step, we could switch
these uses of  ThreadLocal to a UserSession  that would be restored when
running the task

We could use an approach similar to what has been done in Parallel Resource
Download

Maybe we should start this in a feature branch as I guess it's a big piece
of work.

Regards


On Mon, Oct 14, 2019 at 10:10 AM Vladimir Sitnikov <
sitnikov.vladimir@gmail.com> wrote:

> Hi,
>
> Currently, JMeter uses Thread.sleep to implement a delay (e.g. think time).
> This requires lots of execution threads even though most of them will be
> idle waiting on .sleep.
>
> I wonder what if JMeter would offload .sleep() operations to a queue and
> just switch the context to another operation?
> That is it could disassociate JMeterTread from java.lang.Thread, and reuse
> the thread for another task.
>
> For instance, we could put "sleep tasks" to
> java.util.concurrent.DelayQueue, then JMeter threads could fetch tasks from
> the queue.
>
> Any thoughts?
> Was this ever attempted?
>
> Of course, it might break the uses of ThreadLocal<...>, however, it would
> enable to have lots of virtual users with less number of threads
> provided there are think times (which should be a quite common case in my
> opinion).
>
> The implementation might confine the use of "context switch" only in case
> the delay exceeds a pre-defined limit.
> Then small delays could be served as usual (with little to no overhead),
> and big delays would not cause thread starvation.
>
> Vladimir
>


-- 
Cordialement.
Philippe Mouawad.

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