DO NOT REPLY [Bug 13270] New: - Container's AJP13 handler does not setTcpNoDelay on accept

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13270>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13270

Container's AJP13 handler does not setTcpNoDelay on accept

           Summary: Container's AJP13 handler does not setTcpNoDelay on
                    accept
           Product: Tomcat 4
           Version: 4.1.12
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: Connector:JK/AJP (deprecated)
        AssignedTo: tomcat-dev@jakarta.apache.org
        ReportedBy: hanming@apple.com


We have a very simple JSP app that is deployed on TC, integrating with Apache, using either ajp12 or ajp13 protocol. When used with ajp13, we realized that the classic interaction between Nagle algorithm (on the TC side) and delayed ack (on the Apache side) results in 200ms delay per request-response loop on the Mac OS X platform.

Detailed description:

1. The connector that we used is mod_jk, which is capable of ajp12 or ajp13.

2. When we use ajp12, the entire request-response loop takes about 1ms on a LAN. Using tcpdump on the traffic shows no obvious slow down. This is good.

3. Using the same hardware/software setup but just switching to the ajp13 protocol, each request-response is about 200ms. Mac OS X  10.2 (darwin), by default, turns on Nagle and set the delayed ack to be 200ms. So, intuitively, we know that it's probably due to that.

4. Indeed, analyzing the protocol at http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jk2/common/AJPv13.html and the tcp dump confirms this. Experimentally, if I either turn off Nagle on the TC side or turn off delayed ack on the Apache, then performance is as good as ajp12.

5. So there are 2 potentially simple fix:
	a. We could turn off delayed ack on the Apache side but on darwin, there is no such socket level option. Hence, it will affect the entire machine, which is not wise.
	b. Turn off Nagle on the TC side, for ajp13. Analysis of the protocol shows that ajp13 first sends Headers (small load) back to Apache, followed by Body Chunk (big load) and then an End Response (small load). So it's a good candidate for turning off Nagle anyway.

I saw that #2176 was fixed so maybe this has a chance.
Suggestion:

	in org.apache.ajp.Ajp13:189, insert 'socket.setTcpNoDelay(true)' after setSoLinger()

sidenote: Experimenting on RedHat7.2 shows a slowdown as well when using ajp13, though not as dramatic. I was told that RH actually uses a smart kernel algorithm to make the delayed ack non obvious.

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>