On Tue, Jan 16, 2024 at 7:41 AM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> 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.
