Re: [PATCH] Performance Problems in Coyote Chunking

2003-09-15 Thread Steve Appling

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

2003-09-15 Thread Remy Maucherat
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

2003-09-12 Thread Remy Maucherat
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

2003-09-12 Thread Marc Slemko
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

2003-09-11 Thread Remy Maucherat
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]


Re: [PATCH] Performance Problems in Coyote Chunking

2003-09-11 Thread Peter Lin

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]