httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <>
Subject Re: [PATCH] chunked-encoding performance improvement
Date Sat, 08 Feb 1997 02:13:18 GMT
On Sun, 2 Feb 1997, Dean Gaudet wrote:

> Here it is.  This patch eliminates all "wasteful" bflush() calls and
> attempts to be as efficient with write()s as possible without making the
> code too ugly. 
> Essentially it makes the chunk header and trailer a part of the output
> buffer, and maintains enough state in the BUFF to be able to fix up the
> header when it is ready to flush the chunk.  It uses writev() when it's
> not efficient for us to buffer a large write -- i.e. a bwrite() of a large
> block will first fill the buffer, and chunk that, then if the remaining
> part is larger than bufsiz it will be chunked without first copying it to
> a buffer. 
> I added NO_WRITEV which should be defined on platforms that do not have
> writev().  They will experience a performance penalty on those large
> writes, but that's just too bad.  A keen porter could implement a writev() 
> that did userland copying to assemble a single write().  For now,
> NO_WRITEV is not defined anywhere. 

SunOS 4.x doesn't seem to have writev().

> I have tested this on various types of requests, and poured over output
> dumps to ensure it does the right thing.  Chunked encoding is forced when
> the response contains no Content-Length, so testing with CGIs and SSIs is
> a good approach.  At one point I lowered the DEFAULT_BUFSIZE in buff.c in
> order to be sure the large write support was working.
> This may look like a large change this late in the cycle, so I should
> point out that without it the present code spits a packet for the response
> headers, and three packets for each chunk.  This makes persistent
> connections far more expensive than they should be.

I won't +1 it because I don't have time to do a thorough review right
now, but I like the idea and didn't notice anything obviously
wrong.  Are already 3 +1s I think, so...

Have you tested it with NO_WRITEV defined?

View raw message