httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Bloom" <...@covalent.net>
Subject RE: core_output_filter buffering for keepalives? Re: Apache 2.0 Numbers
Date Sun, 23 Jun 2002 14:07:36 GMT
I think we should leave it alone.  This is the difference between
benchmarks and the real world.  How often do people have 8 requests in a
row that total less than 8K?

As a compromise, there are two other options.  You could have the
core_output_filter refuse to buffer more than 2 requests, or you could
have the core_output_filter not buffer if the full request is in the
buffer.

Removing the buffering is not the correct solution, because it does have
a negative impact in the real world.

Ryan

----------------------------------------------
Ryan Bloom                  rbb@covalent.net
645 Howard St.              rbb@apache.org
San Francisco, CA 

> -----Original Message-----
> From: Brian Pane [mailto:bpane@pacbell.net]
> Sent: Sunday, June 23, 2002 9:38 PM
> To: dev@httpd.apache.org
> Subject: core_output_filter buffering for keepalives? Re: Apache 2.0
> Numbers
> 
> On Sun, 2002-06-23 at 20:58, Brian Pane wrote:
> 
> > For what it's worth, I just tried the test case that you posted.  On
my
> > test system, 2.0 is faster when I run ab without -k, and 1.3 is
faster
> > when I run with -k.
> 
> I studied this test case and found out why 2.0 runs faster in the
> non-keepalive case and slower in the non-keepalive case.  It's
> because of the logic in core_output_filter() that tries to avoid
> small writes when c->keepalive is set.  In Rasmus's test, the file
> size is only 1KB, so core_output_filter reads in and buffers the
> contents of 8 requests before it finally reaches the 8KB threshold
> and starts calling writev.  1.3, in contrast, writes out each
> request's response immediately, with no buffering.
> 
> I'm somewhat inclined to remove the buffering in this case, and
> let core_output_filter send the response as soon as it sees EOS
> for each request, even if that means sending a small packet.  I
> just tried this in my working tree, and it does speed up 2.0 for
> this particular test case.  On the other hand, I'm not a fan of
> small write calls in general.
> 
> Anyone else care to offer an opinion on whether we should remove
> the buffering in this situation?
> 
> --Brian
> 



Mime
View raw message