I'm convinced, thank you very much for taking the time to test and analyze this.
We should switch the setting in the main branch - not sure if Remy has a branch for 4.1/4.0, and if he has I think he should decide if he wants this backported. If anything happens we can roll back. I hope we'll hear more from Han Ming in future :-) Costin Han Ming Ong wrote: > [+1] > > Theoretical backup: > > Analyzing the protocol at > http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jk2/common/AJPv13.html > and the tcp dump confirms that ajp13 first sends Headers (small load) > back to Apache, followed by Body Chunk (big load) and then an End > Response (small load). > > I can't draw nice ASCII art but here's the summary for a typical > request-response loop currently (there is a variation with TC getting > body chunk from Apache but not considered here). > > 1. Apache -------> request headers --------> TC > > 2. Apache <------- response headers <-------- TC > > There are 2 scenarios that can happen after this. > > 3a. Apache <------- response body <-------- TC > This happens immediately if size of the response chunk is greater than > MSS or MTU (say 1500 bytes), regardless of whether TCP_NODELAY is on or > off. > > Apache <------- end response headers <-------- TC > > > 3b. Apache -------> DELAYED_ACK --------> TC > Apache <------- response body + end response headers <-------- > TC > > If TCP_NODELAY is off, TC waits for ACK from Apache. However, on Mac > OS X and RedHat, DELAYED_ACK is turned on by default in the OS. On the > Mac OS X, it's 200ms and I think it is 40ms with RH. Hence, if size of > the response chunk is less than say 1500 bytes, there will be a delay > of ~200ms on Mac OS X before Apache sees the body[1]. > > The good thing about this is that the end response headers is usually > coalesced with the response body due to TCP_NODELAY off (Nagle). > > > Now imagine that TCP_NODELAY Is turned on by default, then we would see > the scenario of 3a happening all the time, regardless of size of body. > This will result in faster response. The downside that I see is that > "end response headers" will be sent in a separate packet. > > Some lab results: > > I patched up TC's ajp13 java class and gave the patch to our QA person. > After 4 hours of testing, she reported that > > 1. performance for small body chunks (typical size < 1500) is now on > par with ajp12 > 2. performance for bigger body chunks does not degrade. > > [1] We did almost all our tests on Mac OS X but I ran the test a few > times on RedHat. The degradation doesn't seem to be as bad on Redhat. I > only saw a 50% drop in performance, comparing ajp13 to ajp12. I have > read that Linux kernel is smarter on the DELAYED_ACK algorithm. > > [2] I'm sorry that we didn't do tests on the rest of the platforms > supported by Apache and Tomcat but hopefully, you will be convinced by > the theoretical underpinnings. > > Thank you for your kind attention. Comments and counter-points welcome. > > Han Ming > > On Tuesday, October 8, 2002, at 04:26 AM, Henri Gomez wrote: > >> What about setting tcpnodelay to true by default >> for Ajp13 connectors java implemtations ? >> >> It should fix MacOS X latency problems and should be >> the default for any persistant connections... >> >> Comments welcome... >> -- Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
