tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Lauri" <>
Subject SV: Tomcat JK2 Connector/IIS Slowdown
Date Mon, 13 Dec 2004 04:28:47 GMT
Try some buffertstream. On these browser that have this "fault" can be very
quick when it comes to HTTPS (https have a different packagestructure).


-----Ursprungligt meddelande-----
Från: Robert Walther [] 
Skickat: den 13 december 2004 11:25
Ämne: FW: Tomcat JK2 Connector/IIS Slowdown

For those of you who saw my original posting of this issue, you may
remember that my IIS6/Tomcat 5.028 server was very slow at downloading
files from an online cart to a Windows 2000, IE6 browser.  But the same
IIS6/Tomcat server would download files very quickly to all Netscape /
Mozilla and Safari browsers. Also, I should mention, my Linux/Tomcat
server did not have any speed issues with downloading files to any of
the browsers, including IE6.
Well, after collecting and analyzing many network packet captures, it
turns out the slowness is due to the fact that Microsoft has interpreted
an RFC regarding how to respond to TCP packets, differently than
Netscape / Mozilla and Safari.  This causes some IE6 browsers to respond
very poorly to in some situations,  So, ultimately it is a client-side /
browser issue.  They did give me a suggestion on how to fix it on the
client side, but they did not know of anything that could be done to IIS
or Tomcat to speed-up the file downloads.  Here is their response.
start quote
CASE_ID_NUM: SRX041018608346


********************** The message for you follows
************************ Good Afternoon Rob,

Thank you for using Microsoft Support and Microsoft Internet Products. I
am confirming the closing of your case concerning the delay we were
seeing when downloading a 1MB file to some clients. We confirmed this
can be corrected by adding the TcpAckFrequency registry key described in
article 328890 New registry entry for controlling the TCP Acknowledgment
(ACK) behavior
<>  . We set TcpAckFrequency to a
value of 1, rebooted the XP client machine and when we tested again all
worked fine. If you have Windows 2000 clients that experience the issue,
the parameter is called TCPDelAckTicks and you can set the value to 0.
For the 2000 platform, please refer to article 311833 The TcpDelAckTicks
Registry Value Has No Effects on Ack Timeouts
<>  . There is also a white paper
you may want to review located at
gies/networking/tcpip03.mspx>  . Lastly, the RFC which discusses the
delayed ack can be located at
<>  specifically, you may want to
review section This section states the following which seems to
be relevant to what we were experiencing:

"A TCP SHOULD implement a delayed ACK, but an ACK should not be
excessively delayed; in particular, the delay MUST be less than 0.5
seconds, and in a stream of full-sized segments there SHOULD be an ACK
for at least every second segment." 

Notice the keyword should which leaves some room for interpretation.
Thanks again for calling Microsoft and have a great week!

end quote

I do not believe that Netscape and Mozilla respond with a delayed ACK
when the stream of data is not padded to a full-sized segment.  Also, I
think that IIS6 does not pad packets but Apache does.  Thus, because
IIS6 + Tomcat together send out non-full-sized packets, the IE6 browser
will delay the ACK until multiple partial packets are received.  This
delay causes the slowness.  IF Apache + Tomcat packets ARE full sized
there is no delayed ACK.

It was distressing that Microsoft did not indicate a fix on the server
side.  I was hoping in light of this information, it could be fixed by
padding packets coming out of Tomcat through the jk connector.

Well, I will continue to research this and any feedback or additional
insight would be appreciated,  Also, I may be able to coordinate
Microsoft to help us fix this issue if any one wishes to help me
investigate the jk / Tomcat Source code.

One thing I did not investigate, are other java methods for downloading
files.  It is possible that other java methods would be faster than the
one we used for our online cart.

FYI to all,

Rob Walther

Senior System Architect

InterchangeDigital, Inc.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message