On 20/10/2022 09:32, Rémy Maucherat wrote:
<snip/>
This is interesting since now is the best time to discuss long term plans.
We'll see if there are some scheduling gains with Loom ... But I don't
think thread scheduling was the problem in Tomcat. Maybe lock
concurrency but it seems these had been eliminated (or improved at
least). I still don't understand how it could possibly really work
though, right now it feels like asking if Windows 3 cooperative
multitasking could work (= it works as long as all apps and libraries
are perfectly coded and there's no bug whatsoever). Also having to
avoid native code is annoying (just when there's finally something
good like Panama ...).
I went through the Jakarta Servlet mailing list and there are some
discussions about Loom and a possible lower level API. It seems
there's a discussion between blocking and non blocking APIs. Well, IMO
we need both ...
- Blocking: For Loom. And mostly it could simply be
ServletRequest/Response/Cookie/IS/OS without any of the other items.
So it looks like everything is in there already.
- Async: Great if Loom isn't that appropriate for real work. However,
the listeners used for the Servlet API are not a very nice async API
(of course they are very appropriate as an extension for a blocking
API). So maybe that's where the new work is: come up with an async API
?
What do you think ?
There are a lot of dimensions to this problem space.
I have an initial implementation of the Loom module that supports the
blocking parts of the Servlet API. I am currently working on the
necessary refactoring to optimise that for Loom. I hope to get that
committed later this week or early next.
My working assumption is that any benefits Loom can provide will be in
the blocking API. I don't see any way Loom could support the async and
non-blocking APIs without adding some overhead - even if that overhead
is negligible.
Therefore, rather than moving on to try and implement support for the
async and non-blocking parts of the Servlet API with the Loom connector,
I'd like to spend some time exploring the performance of Loom with the
blocking API. Hopefully, others here will also be able to undertake
their own performance tests.
I have only tested a couple of scenarios that aren't particularly suited
to Loom (requests to a simple servlet) and the results are increased CPU
usage and reduced throughput with Loom compared to NIO. I want to look
at some tests that are more tailored to demonstrate the benefits of Loom.
My expectation is that we will identify some scenarios where switching
to the Loom module provides immediate benefits with no application
changes. What will be interesting is how that compares to refactoring
the application to use async and/or non-blocking.
The other question is the extent to which the refactoring I have
completed so far is necessary. I am not seeing much benefit from the
optimisations I am implementing. It may be that a much simpler approach
of integrating Loom (essentially a custom executor) is good enough. Note
that this may mean undoing some of the refactoring I am currently
implementing in Tomcat 11.
Once we have that data, then I think we'll be in a position to decide
the extent to which it makes sense to support Loom and whether or not to
proceed and implement support for async and non-blocking in the Loom module.
There is clearly a demand for a lower-level HTTP API. The question for
me at this point is whether that should be async based or blocking
(Loom) based. Based on what I have seen so far, I think Greg Wilkins has
called it correctly and that async will have the edge. However, that is
more judgement/instinct than based on hard data. I want to see more data
before making forming a final view.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
