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 Sun, 09 Feb 1997 04:34:04 GMT
-DNO_WRITEV appears to work properly.

Dean

On Fri, 7 Feb 1997, Dean Gaudet wrote:

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