Rémy,
On 10/21/22 05:27, Rémy Maucherat wrote:
On Thu, Oct 20, 2022 at 3:46 PM Rémy Maucherat <r...@apache.org> wrote:
Ok, that is reasonable and seeing what can be expected in the best
case is a good plan. Async will indeed be a bit more expensive with
Loom, just like blocking is more expensive with NIO(2).
I'm starting testing, and it looks like the basics work, as you said.
The first item is to identify a best case scenario for Loom. I decided
to try with a static file (in the context of Tomcat, a low level API
would be very similar in terms of IO), but maybe this is not it and a
Servlet doing computations would be better for Loom (with less IO
load).
Pulling out my good old ab, I have some rather interesting results.
-c 1 (no concurrency) is looking awesome for Loom, where it basically
destroys NIO.
However, it degrades quickly from there. -c 2 is already a lot closer.
-c 5 is the inflexion point where NIO pulls ahead. Then as concurrency
increases Loom becomes slower. Thankfully, it doesn't degrade too much
from there and with high concurrency it remains reasonably close. I
don't have a high core count CPU though so this could make for some
differences as well.
Overall I would say this matches your finding. I tested with my
panama-foreign Java "20" build. We should probably wait for the real
Java 20 to start making decisions.
If the performance of Loom is currently essentially on-par with NIO, my
expectation is that, over time, it will increase quite a bit. I'm sure
there is tons of code in the Loom implementation that can be optimized,
removed, etc. whereas NIO has had a decade of similar optimizations already.
But if we have to have 25% more code to get 5-10% performance
improvement, I'm not sure it's worth it. (I'm sure our colleagues at AWS
will disagree!)
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
