On Wed, Jun 16, 2021 at 11:02 PM Mark Thomas <ma...@apache.org> wrote:
> On 16/06/2021 19:42, Deshmukh, Kedar wrote: > > Thanks Mark for the quick update. > > > > Can you please provide how useAsyncIO="false" makes impact in terms of > performance, scalability (number of connections to the server) and > reliability ? > > Well, if you set useAsyncIO="false" it works. If you set > useAsyncIO="true" it fails 90% of the time. > > I'd suggest that, with that failure rate, discussion of performance and > scalability are somewhat irrelevant. > > With test cases that do not trigger this issue the difference between > the two is marginal. Remy is more familiar with the details than me but > from memory useAsyncIO="true" is a little better on older JREs. On > modern JREs there isn't much in it. It is also likely to depend on > application usage patterns, OS, etc. In short, you'd need to test the > difference on your application with your hardware etc. I'd expect the > difference to be hard to measure. > The main benefit is that it removes some blocking IO which is a good idea. NIO2 is worth testing with your new test, BTW. Transferring large files with HTTP/2 is a bad idea though, it's always going to be inefficient compared to HTTP/1.1. And if the idea is to multiplex, then it will become terrible, that's a given and it should not be done. HTTP/2 is very good only if you have tons of small entities to transfer (that's what sites have these days, so that's good). Rémy > > Mark > > > > > > Regards, > > Kedar > > > > > > -----Original Message----- > > From: Mark Thomas <ma...@apache.org> > > Sent: Wednesday, June 16, 2021 11:41 PM > > To: users@tomcat.apache.org > > Subject: Re: Trouble with HTTP/2 during concurrent bulk data transfer > (server -> client) > > > > On 16/06/2021 18:47, Rémy Maucherat wrote: > >> On Wed, Jun 16, 2021 at 7:36 PM Mark Thomas <ma...@apache.org> wrote: > >> > >>> On 16/06/2021 18:01, Deshmukh, Kedar wrote: > >>> > >>>> I have one additional question at this point. How easy is this issue > >>>> to > >>> reproduce? Does it happen every time? In 10% of requests? 1% ? > >>>> > >>>> [Kedar] It is reproducible 9/10 times in my environment. So 90% time > >>>> it > >>> is reproducible when concurrency is 5 or more and file sizes are > >>> between 1GB-5GB. > >>> > >>> Thanks for the confirmation. I have converted your test classes into > >>> a Tomcat unit test (easy for me to work with) and the issue looks to > >>> be repeatable on Linux with the latest 10.1.x code. > >>> > >>> I'm starting to look at this now. I'll post again when I have more > >>> information. I'm not expecting this to be quick. > > > > Kedar, > > > > If you set useAsyncIO="false" on the Connector that should work around > the problem for now. The Servlet Async API will still be available. > > Tomcat just uses a different code path to write to the network. > > > >> I did not expect it would be so easy to reproduce. Can you commit the > test ? > > > > It is a bit of a hack at the moment. The code isn't particularly clean > and I have hard-coded some file paths for my system (I have a bunch of 5GB > Windows MSDN ISOs I am using for the large files. I also don't think we > want test cases that using multi-GB files running on every test run. > > > > If I clean things up a bit, parameterise the hard-coded paths bits and > disable the test by default it should be in a reasonable state to commit. > > > > It looks very much like the vectoredOperation and the associated > semaphore is where things are going wrong. > > > > I'm aiming to work on this some more tomorrow. > > > > Mark > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
