Virtual vs platform performance at 10K HTTP requests
David
david.vlijmincx at gmail.com
Wed Nov 26 13:25:16 UTC 2025
Hi all,
Thanks for the explanations. I now realize I was looking at it the wrong
way. I treated it as a workload of 10K requests that needed to be executed,
without realizing how much persistent connections would affect the outcome.
Using a semaphore with the same number of permits as platform threads
brought the performance much closer to the platform thread version.
Thanks again for the insights!
Kind regards,
David
On Wed, 26 Nov 2025 at 12:35, Alan Bateman <alan.bateman at oracle.com> wrote:
> On 26/11/2025 10:32, David wrote:
>
>
> I assume it also benefits from being able to use HTTP persistent
>> connections.
>>
>
> Just trying to understand, does that mean that virtual threads don't have
> this? Because running Socket Statistics in the background showing 17K
> established connections while running virtual threads vs 140 when using
> platform threads.
>
> At this point I am just trying to understand where this delay is coming
> from and why virtual threads trigger this.
>
> Persistent connections avoid needing a separate TCP connection for each
> request. LoomBenchmark's FixedPlatformPool appears to use a thread pool
> with 4 workers so it gets to benefit from the having the cached connection.
> Tomcat probably has more configuration to limit/configure the number
> connections to keep alive, probably 100 or 200 by default.
> LoomBenchmark.java's virtualThreadExecutor is a completely different test.
> It attempts to establish 10k concurrent connections, it's probably causing
> connections to be closed and re-established at each iteration.
>
> -Alan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20251126/0dc644ee/attachment.htm>
More information about the loom-dev
mailing list