Thread started/finished logging incur significant overhead when executing many JMeter threads

[vlsi]

Expected behavior

JMeter should support cases when the test produces many threads.

It should probably discard "Thread started", and "Thread is done" messages when the thread startup rate exceeds a certain threshold.

Actual behavior

JMeter executes ~5-10K requests per second only, and it spends significant time on logging "Thread started" and "Thread is done" messages (they synchronize on the logger, and they cause logging pane updates in the UI).

A workaround is to adjust the org.apache.jmeter.threads.JMeterThread logging category to warning level.

Steps to reproduce the problem

Create Open Model Thread Group with debug sampler. Use rate(100000/sec) random_arrivals(60 sec) for the schedule

JMeter Version

5.5

Java Version

No response

OS Version

No response

[ra0077]

Hi Good catch I don't use these logs, +1 to your workaround And it will help for spike test

[pmouawad]

Hello @vlsi , Related to this feature, isn't there some optimization to do related to thread creation/destruction ? Through the use of a Thread Pool for now (until Loom is available , it's in preview in Java 19).

Regards

[vlsi]

OpenModelTG already uses a thread pool, so it does not create/destroy hardware threads.

Currently OMTG creates JMeterThreads in a single thread, and it reaches 160'000 samples per second (infinite loop yields 3M samples per second). It might be a better idea to reuse the cloned plans.

Currently we have a significant memory overhead caused by test elements cloning, so I am not sure virtual threads would change much. We can try them (e.g. call with reflection), however, I am not sure it will yield much for the current JMeter design

[pmouawad]

@vlsi , I was tricked by the log, it's been some time I have not looked at this code, I should have looked before commenting :-), thanks for clarification on the pool existence.