httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <b...@wstoddard.com>
Subject Re: core output filter buffering
Date Wed, 21 Nov 2001 02:58:13 GMT
What is the source of the bytes being written? Is it a pipe? Or a file?

If it is a pipe, you can experience these suboptimal packets because of code in the
content_length filter. The idea is to read bytes from the pipe in non blocking mode. If
the pipe is empty, then flush what you have already read to the network and go back to the
pipe for more.

1.3 behaviour is slightly different. In 1.3, only the first read from the pipe is
nonblocking. If a pipe read returns EWOULDBLOCK, you flush what you have to the net then
all subsequent pipe reads are blocking. We can change this to more closely resemble 1.3
behaviour quite easily although I sort of like the 2.0 behaviour as it is now; you don't
hold bytes up in the server if you don't have to which can be useful for some apps.  The
first pipe read definitely needs to be non blocking though.

Bill

----- Original Message -----
From: "Doug MacEachern" <dougm@covalent.net>
To: <dev@httpd.apache.org>
Sent: Tuesday, November 20, 2001 6:23 PM
Subject: core output filter buffering


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


Mime
View raw message