On Thu, Oct 20, 2022 at 11:28 AM Mark Thomas <ma...@apache.org> wrote: > > 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.
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 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. +1 then. I hope there will be *something* that works more efficiently at least. > 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. Ok, let's wait for the results. I'll test it too. Rémy > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
