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
Date Wed, 21 Nov 2001 04:45:29 GMT
On Tuesday 20 November 2001 03:23 pm, Doug MacEachern wrote:

This is a bug!  A big one at that.  The problem is that you are writing very
small sets of data at one time.  The code tries very hard to use writev if at
all possible, because that will improve our performance.

The problem that we are having in this case, is that once we see 16 buckets,
we send the data no matter how much data we have.  This is just plain wrong.
If we don't have AP_MIN_BYTES_TO_WRITE, we should buffer until we do or
until we get a FLUSH or EOS bucket.

I am looking at this now, expect a patch either late tonight or early tomorrow.
I don't know how extensive the bug is, I need to really look at the core output
filter in detail to fix this.

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

Mime
View raw message