Performance Questions and Poller Implementation in Project Loom

[Rob Bygrave]

FWIW My 2c
- Great comments from Franz
- Benchmarking is pretty hard and takes quite a lot of time and effort
- A description of the benchmark testing I did follows below ...

For my own benchmarking / testing of Virtual Threads I used Jetty with
platform threads vs Jetty with virtual threads and the endpoint had a
configurable amount of "simulated IO wait" using LockSupport. The variables
for this test was:
- Virtual Threads v Platform Threads
- Length of "Simulated IO wait"
- Amount of concurrent load (especially relative to the Jetty max thread
pool size which I left at 200 which is the default)

Note: The Jetty configured max thread pool size for platform threads I left
at the default of 200. This number was important for my test wrt looking at
behaviour when concurrent requests exceed this.

With Helidon 4, I don't think I can do this same style of test because
there isn't a "use platform threads" option with Helidon 4 (which is fine
by me, I'm personally pretty impressed by the simplicity of the Helidon 4
internals which Virtual Threads provides).

I also did a Http Client based test using the JDK HttpClient benchmarking
blocking Virtual Threads vs HttpClient async. The testing I performed using
Jetty and HttpClient gave me a lot of confidence in how Virtual Threads
performed.

Maybe that helps or is interesting. Also, just to say I don't work for
Oracle or the Helidon team but I'm highly interested in using Helidon 4 SE
as my recommended web server going forward.

Cheers, Rob.

On Thu, 2 Nov 2023 at 09:22, Ilya Starchenko <st.ilya.101 at gmail.com> wrote:

> On 1 Nov 2023 at 01:51:44, Francesco Nigro <nigro.fra at gmail.com> wrote:
>
>> Techempower plaintext is highly pipelined (in the worst way, because is
>> http 1.1 and NOT http 2, which is designed for that) and CPU bound, due to
>> http encoding/decoding, especially if the framework is a "proper" one (see
>> my rant at
>> https://github.com/TechEmpower/FrameworkBenchmarks/discussions/7984) and
>> materialize properly the headers; which means that an improvement in that
>> part can be the responsible to achieve better numbers in techempower
>
>
> Franz,
>
>
> Thank you for the clarification. I've already noticed that some of the
> Techempower benchmarks don't accurately represent real-world scenarios, but
> I haven't found another benchmark that would be more representative. I'll
> try profiling and perhaps look for alternative benchmarks (I've heard that
> the Quarkus team is working on some benchmarks).
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20231102/d2455838/attachment.htm>