On 09/01/2015 19:13, Rémy Maucherat wrote: > 2015-01-09 18:45 GMT+01:00 Mark Thomas <ma...@apache.org>: > >> One reason (once all the refactoring is complete) might be WebSocket >> since the use of CompletionHandlers in WebSocket and NIO2 may allow for >> some efficiencies that just aren't possible with NIO or APR. >> > > We'll see. > >> >> I'll add looking at this to my TODO list. Unfortunately, past experience >> suggests tuning this may involve more guess work than I'd like since at >> these sorts of rates profilers tend to add so much overhead you can't >> find the bottleneck you are looking for. >> > > I made a mistake, which also made me think that the NIO connector didn't > suffer from the NPE. In the end, there's no significant improvement there.
That matches my results. NIO is about the same in 8.0.x and 9.0.x for me. >> The other thing to keep in mind is that these performance figures could >> easily shift a lot further as the code clean-up continues. We should >> defer any decision about removing an implementation until after the >> refactoring is complete. Looking further ahead, the HTTP/2 work may >> impact performance as well. >> >> On balance I think we should keep all three implementations since there >> are always likely to be loads that are better suited to one >> implementation than the others. >> > No problem with that. Bingo. The tweaks I made might have provided a few % points but it is the buffering that makes all the difference. I have a local hack that restores it for NIO2 and performance immediately goes up by ~15%. Rather than commit this hack, I am going to work on a more general fix. I should have something early next week. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org