Message-Id: <199701251519.JAA07017@sierra.zyzzyva.com>
To: new-httpd@hyperreal.com
Subject: Re: [PATCH] buff.c bug fix 
In-reply-to: chuck's message of Sat, 25 Jan 1997 07:51:07 -0500.
         <32EA01BB.ABD322C@topsail.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sat, 25 Jan 1997 09:19:51 -0600
From: Randy Terbush <randy@zyzzyva.com>
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@hyperreal.com

> Dean Gaudet wrote:
> > 
> > On Fri, 24 Jan 1997, Roy T. Fielding wrote:
> > 
> > >   * report from some folks at w3c.org about pipelined requests
> > >        Info: http://www.w3.org/pub/WWW/Protocols/HTTP/Performance/Apache.html
> > >        Status: deferred til after 1.2b5, maybe beyond 1.2
> > 
> > I've been looking into this one.
> > 
> > So far I can see a definite bug in bcwrite().  It's probably due to
> > the assumption that if r=write(f,b,n) then r is one of -1, or n unless
> > f is non-blocking.  That isn't the case, all values -1 <= r <= n are
> > possible for any f.  I notice later on in bwrite() that it also indicates
> > that assumption... but the bwrite() code looks ok on my first reading.
> > 
> > In particular, looking through the linux kernel code (the w3 report used
> > linux 2.0.18 for the server) I notice that it's possible if the tcp stack
> > can't get memory during a write() and has to block to do it but received
> > an unblocked signal then it returns a partial write().  There are also
> > other cases that will return partial write()s.
> > 
> > Included is a patch that fixes bcwrite().  (A better performance patch
> > would use writev() to write the three pieces.)  I've lightly tested it...
> > although I'm not really sure how to test chunked encoding.
> > 
> > Also included in this patch is a performance fix for a case where bwrite()
> > would return while having a full buffer.
> > 
> > Plus a fix to remove an unused variable in bflush().
> > 
> Very nice. +1 if this passes Henrik's muster.
> 
> I don't think this is the cause of all the slowness of 1.2 relative to
> 1.1, though. I suspect it's time to think about a hashed child status
> list. I think we'll find most of the slowness there. Randy, did you ever
> try profiling without mod_status in the mix?

Not yet. Enough things changed this past few days that I thought I
would give this another go sometime next week.