>Now java 21 has integrated Virtual Threads , isn't it the time to use it,
I'm +0 regarding that. Of course, we might try adding "use virtual threads" property to a Thread Group and check how it would behave. However, I would not expect much out of it. It might produce hype, however, I doubt it would produce significant gains except for "ok, you might help OpenJDK team to test Virtual Thread implementation by trying JMeter with Virtual Threads". The major memory consumption would still be caused by JMeter's approach of test plan cloning. In our cases, HTTP Header Manager cloning virtually kills us: JMeter recorder creates HTTP Header Managers for every HTTP sampler, and every manager consumes **a lot** of memory since every header is stored in JMeter's quite sparse "JMeterProperty -> Arguments -> name -> value". See https://github.com/apache/jmeter/pull/727 At the same time, we can't easily mark all HTTP Header Managers as "safe for reuse across threads" since there might be cases when the JMX uses JSR223 to access and modify HTTP Header Manager properties **during test execution**. >ended with a PR from Vladimir using Kotlin Co-Routines which >never got merged. The key reasons the PR was not merged are: a) Lack of relevant testing. I never got use cases when a new approach would be needed. The much more needed feature in that regard is "concurrency limiter" (see https://github.com/apache/jmeter/issues/5966). b) A major part of the change (see https://github.com/apache/jmeter/pull/540) was to **add** support for non-blocking HTTP clients: Apache HTTP5 Async client and Jetty async client. Unfortunately, the clients did not play well with the load testing we needed. What we need is to be able to simulate the load generated by **multiple** clients each having their cookies, connection pool, source IP address, and so on. Unfortunately, as I attempted various HTTP clients, almost all of them created **a thread pool of 8+ threads** for **each new HTTP client**. For a typical application, having one thread pool of 8 threads for all HTTP communication is fine, however, JMeter wants to have "HTTP client per virtual user", so we can't afford "a thread pool per virtual user" :) Things might have changed since then, however, that limitation was significant then. I have not tried https://apple.github.io/servicetalk//servicetalk/0.33/index.html yet Vladimir
