httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Holsman <i...@cnet.com>
Subject Re: core output filter buffering
Date Wed, 21 Nov 2001 18:29:21 GMT
On Wed, 2001-11-21 at 10:14, Ryan Bloom wrote:
> On Tuesday 20 November 2001 03:23 pm, Doug MacEachern wrote:
> 
> Okay, I have looked at this again.  I have a patch, but it is doing too much
> buffering now.  :-(  I'm hoping to fix this soon.  However, there is a 
> misunderstanding in the question below that I want to clear up.  We try
> to buffer up to AP_MIN_BYTES_TO_WRITE in the core, never more than
> that.  With that logic, the behavior you are seeing is correct.  However,
> you are seeing the correct behavior because of the values that you chose.
> :-)
> 
Hey Ryan.
while your looking at buffering 
is there any way to buffer the stuff up over brigades?
mod-include creates a seperate brigade per virtual include and you can
get lots of small packets being sent 

> If you use
> 
> GET /test?20,500
> 
> You will see two writes, one for 476, and one for 200.  That is incorrect.
> 
> Ryan
> 
> > can someone explain how the core output buffering is supposed to work?
> > if you look at
> > httpd-test/perl-framework/c-modules/test_pass_brigade/mod_test_pass_brigade
> >.c this intentionally creates a brigade with just one bucket and calls
> > ap_pass_brigade with that bucket.  you can make a request like so:
> > http://localhost:8529/test_pass_brigade?1024,500000
> > which means use a buffer size of 1024 bytes and send 500k total.
> > with the patch below for tracing i see this in the error_log:
> > writev 15543 bytes
> > writev 16384 bytes
> > writev 10240 bytes
> > writev 8192 bytes
> > ... a bunch of 8192's ...
> > writev 7456 bytes
> > writev 0 bytes
> >
> > then with 8192,500000:
> > writev 41143 bytes
> > writev 8192 bytes
> > ... a bunch of 8192's ...
> > writev 288 bytes
> > writev 0 bytes
> >
> > is this the expected behavior?  reason i am asking is that mod_ssl pretty
> > much does what mod_test_pass_brigade.c does with 8192 size buffers.  i
> > have a patch in the works to optimize that, but want to make sure core
> > output filter is behaving as expected first.  i thought it would buffer
> > until it could fill AP_MIN_BYTES_TO_WRITE * MAX_IOVEC_TO_WRITE.  but then
> > again, i guess there is a reason it doesn't, since the OLD_WRITE filter
> > does its own buffering.  insight greatly appreciated, thanks.
> >
> > p.s.
> > i realize the answer is probably buried in the archives, maybe somebody
> > wants to write a documented summary?
> >
> > --- server/core.c       2001/11/19 22:36:20     1.100
> > +++ server/core.c       2001/11/20 22:52:56
> > @@ -3201,7 +3201,7 @@
> >          }
> >          else {
> >              apr_size_t unused_bytes_sent;
> > -
> > +            fprintf(stderr, "writev %d bytes\n", nbytes);
> >              rv = writev_it_all(net->client_socket,
> >                                 vec, nvec,
> >                                 nbytes, &unused_bytes_sent);
> 
> -- 
> 
> ______________________________________________________________
> Ryan Bloom				rbb@apache.org
> Covalent Technologies			rbb@covalent.net
> --------------------------------------------------------------
-- 
Ian Holsman          IanH@cnet.com
Performance Measurement & Analysis
CNET Networks   -   (415) 344-2608


Mime
View raw message