Virtual vs platform performance at 10K HTTP requests

[David]

Hi,

There seems to be a limit causing a 12-30 second delay after establishing
~8K connections too quickly. 10K platform threads do not see or reach this
limit.

The simplest workaround I found was adding System.out.println("1"); right
before making each request. The synchronized lock is probably doing the
heavy lifting here. This makes the platform and virtual threads perform
about the same.

Increasing the server-side Tomcat settings also resolves the stalling:

   - server.tomcat.accept-count=10000
   - server.tomcat.max-connections=20000
   - server.tomcat.threads.max=500
   - server.tomcat.threads.min-spare=50

However, with these higher server limits, I'm seeing different throughput
characteristics:

   - Platform threads: 2.3 ops/s
   - Virtual threads: 0.9 ops/s (about half the speed)


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.

Thanks in advance!

Kind regards,
David



On Wed, 26 Nov 2025 at 10:33, Alan Bateman <alan.bateman at oracle.com> wrote:

>
>
> On 26/11/2025 00:25, Robert Engels wrote:
> > Your platform test is limiting to at most 4 outstanding requests.
>
> I assume it also benefits from being able to use HTTP persistent
> connections.
>
> The benchmark using virtual threads is very different, it tries to
> establish 10k connections in a burst. Do you know what connection
> backlog is used by Tomcat? It may require adjusting net.core.somaxconn
> (kern.ipc.somaxconn on macOS) and other settings. ~8100 may be 8k and
> maybe there is something in the Tomcat or Spring connection that
> controls this.
>
> -Alan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20251126/2215e785/attachment.htm>