On Tue, Jan 16, 2024 at 7:41 AM Vladimir Sitnikov < [email protected]> wrote:
> >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. > That's not my understanding of what Virtual Threads provide: - https://www.theserverside.com/tip/A-primer-on-Java-21-virtual-threads-with-examples > It might produce hype, however, I doubt it would produce significant gains > My understanding is that Virtual Threads brings the benefit of async without its complexity ( https://docs.oracle.com/en/java/javase/21/core/virtual-threads.html#GUID-B163BC51-039B-43BD-87ED-27BE384B509D) through the use of Continuation. When running a test, JMeter threads are frequently waiting for IO so they would highly benefit from this, so from a theoretical perspective I don't understand this argument. Besides, it didn't look that hard to benefit from this, as we need to: - Change create of Threads to Virtual Threads - replace synchronized with Read/Write Lock - Possibly replace where possible the use of Thread Local for expensive objects - Replace for Parallel Download which uses a Thread Pool by Semaphore Not sure we would still need to switch to Async HTTP Client. > except for > "ok, you might help OpenJDK team to test Virtual Thread implementation by > trying JMeter with Virtual Threads". > I have nothing against helping OpenJDK team if it also helps JMeter getting more scalable. > The major memory consumption would still be caused by JMeter's approach of > test plan cloning. > Maybe it won't help on memory side, but it will help on CPU side and increase scalability. > 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 > -- Cordialement. Philippe Mouawad.
