<div dir="ltr">Hi all,<br><br>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.<br><br>Thanks again for the insights!<br><br>Kind regards,<br>David<br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, 26 Nov 2025 at 12:35, Alan Bateman <<a href="mailto:alan.bateman@oracle.com">alan.bateman@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><u></u>

  
  <div>
    <div>On 26/11/2025 10:32, David wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr"><br>
        <div>
          <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">I
            assume it also benefits from being able to use HTTP
            persistent<span> </span><br>
            connections.<br>
          </blockquote>
          <div><br>
          </div>
          <div>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.</div>
          <div><br>
          </div>
          <div>At this point I am just trying to understand where this
            delay is coming from and why virtual threads trigger this.</div>
          <br>
        </div>
      </div>
    </blockquote>
    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.<br>
    <br>
    -Alan<br>
  </div>

</blockquote></div>