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 < [email protected]> 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.
