httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruediger Pluem <>
Subject Re: strange usage pattern for child processes
Date Sun, 19 Oct 2008 13:06:18 GMT

On 10/19/2008 01:21 PM, Ruediger Pluem wrote:
> On 10/18/2008 10:22 PM, Graham Leggett wrote:
>> Ruediger Pluem wrote:
>>>    Plus the default socket and TCP buffers on most OS should be already
>>>    larger then this. So in order to profit from the optimization the time
>>>    the client needs to consume the ProxyIOBufferSize needs to be
>>> remarkable.
>> It makes no difference how large the TCP buffers are, the backend will
>> only be released for reuse when the frontend has completely flushed and
> Sorry I maybe wrong here, but I don't think this is the case. If there is
> space left in the TCP buffer you write to the socket non-blocking and the
> data seems to be processed for the sending process then. It does not block
> until the data is sent by the OS. And even flush buckets do not seem to cause
> any special processing like a blocking flush. So returning to your CNN
> example I am pretty much sure that if the TCP buffer for the socket of the
> client connection holds 92k plus the header overhead your connection to the
> backend will be released almost instantly.
> I don't even think so that a close or shutdown on the socket will block until
> all data in the TCP buffer is sent. But this wouldn't matter on keepalive
> connection to the client anyway since the connection isn't closed.

I did some further investigations in the meantime. Using the following configuration

ProxyPass /cnn/
Sendbuffersize 285168
ProxyIOBufferSize 131072

and the following "slow" testclient

!/usr/bin/perl -w

use strict;
use Socket;

my $proto;
my $port;
my $sin;
my $addr;
my $url;

my $oldfh;

$proto = getprotobyname('tcp');
$port = getservbyname('http','tcp');
$addr = "";
$url = "/cnn/";

$sin = sockaddr_in($port,inet_aton($addr));
$oldfh = select SOCKET_H;
$| = 1;
select $oldfh;
print SOCKET_H "GET $url HTTP/1.0\r\n\r\n";
close SOCKET_H;

I was able to have the connection to returned back to the pool
The strange thing that remains is that I needed to set the Sendbuffersize about
3 times higher than the actual size of the page to get this done. I currently
do not know why this is the case.

Another maybe funny sidenote: Because of the way the read method on socket buckets
work and the way the core input filter works, the ap_get_brigade call when processing
the http body of the backend response in mod_proxy_http never returns a brigade that
contains more then 8k of data no matter what you set for ProxyIOBufferSize.
And this is the case since 2.0.x days. So the optimization was always limited to
sending at most 8k and in this case the TCP buffer (the send buffer) should have
fixed this in many cases.



View raw message