RE: Tomcat JK2 Connector/IIS Slowdown
OK, I did not try the test under ssl. I'll let you know what happens. Thanks, Rob -Original Message- From: Peter Lauri [mailto:[EMAIL PROTECTED] Sent: Sunday, December 12, 2004 10:29 PM To: 'Tomcat Users List' Subject: SV: Tomcat JK2 Connector/IIS Slowdown Try some buffertstream. On these browser that have this fault can be very quick when it comes to HTTPS (https have a different packagestructure). /Peter -Ursprungligt meddelande- Från: Robert Walther [mailto:[EMAIL PROTECTED] Skickat: den 13 december 2004 11:25 Till: [EMAIL PROTECTED] Ä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 MESSAGE: ** 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 http://support.microsoft.com/?id=328890 http://support.microsoft.com/?id=328890 . 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 http://support.microsoft.com/?id=311833 http://support.microsoft.com/?id=311833 . There is also a white paper you may want to review located at http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technolog ies/networking/tcpip03.mspx#XSLTsection129121120120 http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technolo gies/networking/tcpip03.mspx . Lastly, the RFC which discusses the delayed ack can be located at http://www.faqs.org/rfcs/rfc1122.html http://www.faqs.org/rfcs/rfc1122.html specifically, you may want to review section 4.2.3.2. 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL
SV: Tomcat JK2 Connector/IIS Slowdown
Try some buffertstream. On these browser that have this fault can be very quick when it comes to HTTPS (https have a different packagestructure). /Peter -Ursprungligt meddelande- Från: Robert Walther [mailto:[EMAIL PROTECTED] Skickat: den 13 december 2004 11:25 Till: [EMAIL PROTECTED] Ä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 MESSAGE: ** 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 http://support.microsoft.com/?id=328890 http://support.microsoft.com/?id=328890 . 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 http://support.microsoft.com/?id=311833 http://support.microsoft.com/?id=311833 . There is also a white paper you may want to review located at http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technolog ies/networking/tcpip03.mspx#XSLTsection129121120120 http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technolo gies/networking/tcpip03.mspx . Lastly, the RFC which discusses the delayed ack can be located at http://www.faqs.org/rfcs/rfc1122.html http://www.faqs.org/rfcs/rfc1122.html specifically, you may want to review section 4.2.3.2. 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 MESSAGE: ** 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 http://support.microsoft.com/?id=328890 http://support.microsoft.com/?id=328890 . 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 http://support.microsoft.com/?id=311833 http://support.microsoft.com/?id=311833 . There is also a white paper you may want to review located at http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technolog ies/networking/tcpip03.mspx#XSLTsection129121120120 http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technolo gies/networking/tcpip03.mspx . Lastly, the RFC which discusses the delayed ack can be located at http://www.faqs.org/rfcs/rfc1122.html http://www.faqs.org/rfcs/rfc1122.html specifically, you may want to review section 4.2.3.2. 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.
RE: Tomcat JK2 Connector/IIS Slowdown
Bret and Robert, I would suggest that getting a packet trace is the next step in tracking down your performance problem. If you don't already have such a tool, Ethereal is a top notch open-source tool for this which is distributed with linux, but also freely available for windows and mac at www.ethereal.com. I would capture and compare two downloads, one fast and one slow, keeping as many other variables the same as possible. From the test scenarios Robert outlined, I would suggest comparing tomcat/jk2/IIS6 -- w2k/IE6 with tomcat/jk2/IIS6 -- wXP/IE6. When you compare them, here are the kind of things I would look for: 1. Is there some kind of lengthy exchange happening in one that is not in the other? 2. Is the connection failing repeatedly and being automatically retried by the client? 3. Are a lot of packets getting resent in one, i.e. failing to be acknowledged in a timely fashion? 4. Is the process just running slower, and if so, who is slowing it down? (all the packets are timestamped. It's pretty easy to see if the server is slow to send the response, and/or send additional packets when others in the window have been ACKed by the client, or to see if the client is slow to ACK packets, and so the server, once it's window is full, must wait for the client before it can send more.) 5. Is there anything different about the headers exchanged, other than the platform indicated in the User-Agent header.
Tomcat JK2 Connector/IIS Slowdown
Hi Everyone, I'm having some JSP performance problems using the JK2 Connector between Tomcat 5 and IIS6 in Windows Server 2003. If I hit my site as mySite:8080, everything works fine. However, if i just hit mySite, thus going through the JK2 connector, the performance of the JSP pages greatly decreases (load times are about 4-5 times greater). Even stranger is that this slowdown occurs only on some computers and not others. I have already tried setting the enableLookups=false attribute in the server.xml file, but this does not have any effect. Can someone recommend other steps I can follow to improve the performance of my JSP pages when going through the JK2 connector? Thanks, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat JK2 Connector/IIS Slowdown
Brett, I have a similar problem. But what is interesting is that it only seem slow when I test using a Windows 2000 pro box using IE 6 against a Windows 2003 Server. Try using an XP pro box to test the same functionality. Also, here are diagrams that explain the situation I am having. I have submitted the issue to Microsoft and have one of their engineers on the case. I will keep everyone posted on what they discover. (please view this email in plain text for diagrams to display correctly below) File Download from ONE is slow, ALL others are FAST Windows 2003 Server:Windows 2000 Professional |---| |---| | Tomcat 5.0.28 | SLOW| | | IIS6|- | IE6 | | JK2 | FROM CART | | |---| |---| Windows 2003 Server:Windows 2000 Professional |---| |---| | Tomcat 5.0.28 | FAST| ANY OTHER | | IIS6|- | BROWSER | | JK2 | FROM CART| | |---| |---| Windows 2003 Server:Windows XP and Mac OSX |---| |---| | Tomcat 5.0.28 | FAST| IE 6 | | IIS6|- | or Safari | | JK2 | FROM CART| | |---| |---| Windows 2003 Server:ALL recent OS's |---| |---| | Tomcat 5.0.28 | FAST| All recent| | (running on |- | browsers | | port 8080 standalone) | FROM CART| | |---| |---| RedHat LinuxALL recent OS's |---| |---| | Tomcat 5.0.28 | FAST| All recent| | Apache 2.0.x|- | browsers | | JK2 | FROM CART| | |---| |---| Downloading a 1.3M file from a website cart to a Windows 2000 Pro desktop running latest IE 6 is slow and takes 15 seconds Downloading the same 1.3M file to a Windows XP box running IE 6, a Windows Pro box running Mozilla, and a Mac OSX running safari takes approx 1 second Spoke with Microsoft, we put a 1M file in a virtual directory on IIS. It downloaded in approx 1 second to Windows Pro / IE6. When I take IIS/mod_jk out of the picture, and go directly to Tomcat on 8080 the download is fast to All OS's and Browsers. Also, Apache has no problem downloading the file fast to All OS / browser combinations, including Windows 2000 / IE6!!! So does anyone know why the download is slow between IIS 6 and Windows 2000 Pro / IE6 and fast to all other clients. Is there something I can do to my IIS server to make the download go faster. Two other facts that are important... 1. the file being downloaded from the cart is on a remote file server and is being published through IIS via a UNC path from a shared folder. This is true for all scenarios shown above. And, 2. We are required to run IIS 6 in IIS 5 isolation mode due to the isapi_redirector2.dll can not handle IIS 6 native mode under large loads. I did try to do the download running IIS 6 in native mode, but the download was still slow. Seems to be a weird buffer restriction when IIS 6 and IE6 on Windows 2000 talk to each other. Confounded. Any suggestions -Original Message- From: Brett Parsons [mailto:[EMAIL PROTECTED] Sent: Thursday, November 04, 2004 1:45 PM To: [EMAIL PROTECTED] Subject: Tomcat JK2 Connector/IIS Slowdown Hi Everyone, I'm having some JSP performance problems using the JK2 Connector between Tomcat 5 and IIS6 in Windows Server 2003. If I hit my site as mySite:8080, everything works fine. However, if i just hit mySite, thus going through the JK2 connector, the performance of the JSP pages greatly decreases (load times are about 4-5 times greater). Even stranger is that this slowdown occurs only on some computers and not others. I have already tried setting the enableLookups=false attribute in the server.xml file, but this does not have any effect. Can someone recommend other steps I can follow to improve the performance of my JSP pages when going through the JK2 connector? Thanks, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
