[+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... > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
