Re: Coyote Performance Problems with HTTP1.1
Steve Appling wrote: Remy Maucherat wrote: Look, there's no reason to start whining. Adding a lower level buffering (using a ByteChunk maybe) is nearly trivial, and since you seem to know what you're doing, you could have done in less than the amount it took you to write your email. I'm not convinced it's the best solution all the time (Coyote leverages the buffering mandated by the higher level - the servlet API - to avoid useless copying from buffer to buffer). -1 for option 2 (I consider keepalive is more important than anything else). I am perfectly willing to work on this, but it did not seem trivial to someone not familiar with the coyote connector. I need to be able to point out issues (and find out if they really are problems) without being accused of whining. Well, I thought the code which outputs the bytes would be simple enough. I will experiment. I'm not thrilled on buffering (the compression stuff should probably be the one doing more buffering, and I can add a simple trick - in most situations - to the chunking algorithm to prepend the chunk header to the chunk data buffer). You seem to imply that keepalive is tied to chunking - I believe these are independent and chunking could be disabled without sacrificing keepalive. This is not correct. Most JSPs can't keepalive without chunking. And many servlets are the same (a lot of people think doing out.flush followed by out.close when finishing handling the request is a good idea). Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Coyote Performance Problems with HTTP1.1
Howdy, My experience agree with what Senor Lin is saying: chunking increases performance on slow connections for large static files. We have many of these in our webapps and I observed a nice performance increase when moving to the Coyote connector without changing any of our code. Yoav Shapira Millennium ChemInformatics -Original Message- From: Peter Lin [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 10, 2003 9:22 PM To: Tomcat Developers List Subject: Re: Coyote Performance Problems with HTTP1.1 I don't know about others, but my feeling is chunking is useful for large files and not necessarily where the size of the content is unknown at the beginning of the response. I seriously doubt a 2-5K static file would see a real benefit. We all know the internet has a ton of packet collision. therefore, sending non-chunked response over a slow connection would have a higher rate of failure. I haven't been on a modem in a long time, but if memory serves me correctly, downloading a 200K zip file on a modem tends to be faster with chunked encoding than non-chunked. Even with smart download, I remember chunked encoding being faster for large files. I could be wrong. peter --- 3 - When to chunk I thought that chunking was invented to handle serving up dynamically created content that did not have a size known in advance. I believe that on both IIS and Apache static content is not chunked. Is there any way for tomcat to behave similarly - could the default servlet do something to prevent the connector from chunking the data it serves up? If you made it this far, thanks for taking the time to read this and consider my questions. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Coyote Performance Problems with HTTP1.1
Steve Appling wrote: Chunked encoding with the coyote http1.1 connector seems to be very inefficient. I have 3 major comments about it which I will summarize, then explain in more detail for those interested. 1) There are some performance problems with the current implementation of chunked encoding. 2) I would like to be able to turn off chunked encoding completely, but this does not appear to be an option. 3) Chunked encoding should probably only be used when returning content of indeterminate length. Static files served up by the default servlet should perhaps not be chunked. Look, there's no reason to start whining. Adding a lower level buffering (using a ByteChunk maybe) is nearly trivial, and since you seem to know what you're doing, you could have done in less than the amount it took you to write your email. I'm not convinced it's the best solution all the time (Coyote leverages the buffering mandated by the higher level - the servlet API - to avoid useless copying from buffer to buffer). -1 for option 2 (I consider keepalive is more important than anything else). Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Coyote Performance Problems with HTTP1.1
you have to love this reply!!! ;) filip - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Wednesday, September 10, 2003 3:05 PM Subject: Re: Coyote Performance Problems with HTTP1.1 Steve Appling wrote: Chunked encoding with the coyote http1.1 connector seems to be very inefficient. I have 3 major comments about it which I will summarize, then explain in more detail for those interested. 1) There are some performance problems with the current implementation of chunked encoding. 2) I would like to be able to turn off chunked encoding completely, but this does not appear to be an option. 3) Chunked encoding should probably only be used when returning content of indeterminate length. Static files served up by the default servlet should perhaps not be chunked. Look, there's no reason to start whining. Adding a lower level buffering (using a ByteChunk maybe) is nearly trivial, and since you seem to know what you're doing, you could have done in less than the amount it took you to write your email. I'm not convinced it's the best solution all the time (Coyote leverages the buffering mandated by the higher level - the servlet API - to avoid useless copying from buffer to buffer). -1 for option 2 (I consider keepalive is more important than anything else). Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Coyote Performance Problems with HTTP1.1
I don't know about others, but my feeling is chunking is useful for large files and not necessarily where the size of the content is unknown at the beginning of the response. I seriously doubt a 2-5K static file would see a real benefit. We all know the internet has a ton of packet collision. therefore, sending non-chunked response over a slow connection would have a higher rate of failure. I haven't been on a modem in a long time, but if memory serves me correctly, downloading a 200K zip file on a modem tends to be faster with chunked encoding than non-chunked. Even with smart download, I remember chunked encoding being faster for large files. I could be wrong. peter --- 3 - When to chunk I thought that chunking was invented to handle serving up dynamically created content that did not have a size known in advance. I believe that on both IIS and Apache static content is not chunked. Is there any way for tomcat to behave similarly - could the default servlet do something to prevent the connector from chunking the data it serves up? If you made it this far, thanks for taking the time to read this and consider my questions. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software
Re: Coyote Performance Problems with HTTP1.1
Remy Maucherat wrote: Look, there's no reason to start whining. Adding a lower level buffering (using a ByteChunk maybe) is nearly trivial, and since you seem to know what you're doing, you could have done in less than the amount it took you to write your email. I'm not convinced it's the best solution all the time (Coyote leverages the buffering mandated by the higher level - the servlet API - to avoid useless copying from buffer to buffer). -1 for option 2 (I consider keepalive is more important than anything else). I am perfectly willing to work on this, but it did not seem trivial to someone not familiar with the coyote connector. I need to be able to point out issues (and find out if they really are problems) without being accused of whining. You seem to imply that keepalive is tied to chunking - I believe these are independent and chunking could be disabled without sacrificing keepalive. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
