Re: [PATCH] Performance Problems in Coyote Chunking
Steve Appling wrote: Remy Maucherat wrote After testing and benching, implementing buffering at the lower layer is much better, as it avoids introducing complexity in all the levels of processing, and is more powerful. The performance impact of the new behavior is minimal (using a worst case scenario of a static file, the difference is about 2-3%). I believe the updated implementation will meet your needs. What's the most optimal packet size overall, BTW ? 1500 ? Thanks, Remy - I ran my original test again with your new buffered connector. My test page now loads using only 5 packets (same as Apache). The low level buffereing is much cleaner than the approach I was suggesting. I experimented both solutions, and the low level buffering ended up being the best. I thought it would have a performance impact, but it is actually totally insignificant (I did try the worst case - serving a static file, which doesn't need buffering in the first place). It was also very easy to implement using a ByteChunk. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] Performance Problems in Coyote Chunking
Remy Maucherat wrote > After testing and benching, implementing buffering at the lower layer is > much better, as it avoids introducing complexity in all the levels of > processing, and is more powerful. The performance impact of the new > behavior is minimal (using a worst case scenario of a static file, the > difference is about 2-3%). > I believe the updated implementation will meet your needs. > > What's the most optimal packet size overall, BTW ? 1500 ? > > Remy > Thanks, Remy - I ran my original test again with your new buffered connector. My test page now loads using only 5 packets (same as Apache). The low level buffereing is much cleaner than the approach I was suggesting. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] Performance Problems in Coyote Chunking
On Fri, 12 Sep 2003, Remy Maucherat wrote: > Steve Appling wrote: > > > The following patch combines the 3 packets that were generated for each > > chunk into just one packet. There are more optimizations elsewhere - I'll > > keep looking. > > > > Patch of org.apache.coyote.http11.filters.ChunkedOutputFilter from 4.1.27 > > src. > > After testing and benching, implementing buffering at the lower layer is > much better, as it avoids introducing complexity in all the levels of > processing, and is more powerful. The performance impact of the new > behavior is minimal (using a worst case scenario of a static file, the > difference is about 2-3%). > I believe the updated implementation will meet your needs. > > What's the most optimal packet size overall, BTW ? 1500 ? there is nothing inherently relating chunk sizes in chunked output to packet sizes. >From the network perspective, you want some reasonably sized (at a minimum 8k; that is what Apache uses) buffer between the code generating content and the network, and you never want to explicitly flush that to the network unless you are actually at the end of a response. You have no idea what the MTU on the network is, and your code shouldn't care. It should just present the data to the network stack in as big of a buffer as practical (ie. in one write call), and let it worry about that. You don't want to be creating HTTP chunks arbitrarily, you only want to do that when you are writing a buffer to the network layer. Normally one HTTP chunk should span multiple packets when the network layer puts it on the wire. In an ideal world, you could just use a GatheringByteChannel to present the chunk header and the chunk to the network layer at the same time (ie. ala writev()), but compatibility issues are a problem for now. In addition, when serving truly static content where you can determine the content length in advance (eg. serving an image from disk), avoiding chunking alltogether and just setting a content length is definitely preferred. At the end, if you are sending a response with 300 bytes of headers and 800 bytes of content, the content should be in at most one chunk and the headers and content should end up on the network in the same packet, assuming a MTU of at least 1500. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] Performance Problems in Coyote Chunking
Steve Appling wrote: The following patch combines the 3 packets that were generated for each chunk into just one packet. There are more optimizations elsewhere - I'll keep looking. Patch of org.apache.coyote.http11.filters.ChunkedOutputFilter from 4.1.27 src. After testing and benching, implementing buffering at the lower layer is much better, as it avoids introducing complexity in all the levels of processing, and is more powerful. The performance impact of the new behavior is minimal (using a worst case scenario of a static file, the difference is about 2-3%). I believe the updated implementation will meet your needs. What's the most optimal packet size overall, BTW ? 1500 ? Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] Performance Problems in Coyote Chunking
maybe I'm missing something, but http1.0 doesn't support chunking. isn't it feasible to just make tomcat respond with http1.0 instead for this particular problem? I'm probably being naive here, but you could use the older connector instead. peter --- Remy Maucherat <[EMAIL PROTECTED]> wrote: > Steve Appling wrote: > > The following patch combines the 3 packets that > were generated for each > > chunk into just one packet. There are more > optimizations elsewhere - I'll > > keep looking. > > > > Patch of > org.apache.coyote.http11.filters.ChunkedOutputFilter > from 4.1.27 > > src. > > The patch is bad right now, because an exception > will likely occur if > the buffer needs to grow (as it has no sink). But I > get the idea. > > Remy > > > - > 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 http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] Performance Problems in Coyote Chunking
Steve Appling wrote: The following patch combines the 3 packets that were generated for each chunk into just one packet. There are more optimizations elsewhere - I'll keep looking. Patch of org.apache.coyote.http11.filters.ChunkedOutputFilter from 4.1.27 src. The patch is bad right now, because an exception will likely occur if the buffer needs to grow (as it has no sink). But I get the idea. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
