httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: [PATCH] chunked-encoding performance improvement
Date Sat, 08 Feb 1997 02:25:19 GMT
-DNO_WRITEV is essentially the code that we're running right now (i.e.
write_it_all and such).  But sorry I didn't test it :(  I'll see if I can
get a chance to this weekend.

Dean

On Fri, 7 Feb 1997, Marc Slemko wrote:

> 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?
> 
> 


Mime
View raw message