[POLL/VOTE] tcpnodelay to true by default ?
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]
Re: [POLL/VOTE] tcpnodelay to true by default ?
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... +1 - if it doesn't affect any existing usecase. It shouldn't. -- Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [POLL/VOTE] tcpnodelay to true by default ?
[+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]
Re: [POLL/VOTE] tcpnodelay to true by default ?
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]
Re: [POLL/VOTE] tcpnodelay to true by default ?
Costin Manolache wrote: 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. There's no branch at all in j-t-c. I think I'm +1 for it. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [POLL/VOTE] tcpnodelay to true by default ?
Costin Manolache wrote: 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'll make the change in JTC for Ajp connectors. I hope we'll hear more from Han Ming in future :-) Hope so, welcome Apple members. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
