> > > Yes, as Joshua posted today morning (at least it was morning in
> > germany :-),
> > > the application buffer size is hardcoded, the size is 8192 (named
> > > IOBUFSIZE). You will find it in proxy_util.c:ap_proxy_send_fb().
> > >
> > > The ProxyReceiveBufferSize set the receive buffer size of the socket, so
> > > it's an OS issue.
> >
> > Which means that setting of ProxyReceiveBufferSize higher than 8k is
> > usless unless you modify the sources. Am I right? (I want to make it as
> > clear as possible i in the Guide)
> >
>
> No, that means that Apache reads (and writes) the data of the request in
> chunks of 8K, but the OS is providing a buffer with the size of
> ProxyReceiveBufferSize (as far as you don't hit a limit). So the proxied
> request data is buffered by the OS and if the whole page fit's inside the OS
> buffer the sending Apache should be imediately released after sending the
> page, while the proxing Apache can read and write the data in 8 K chunks as
> slow as the client is.
Gerald, thanks for your answer.
I'm still confused... which is the right scenario:
1) a mod_perl process generates a response of 64k, if the
ProxyReceiveBufferSize is 64k, the process gets released immediately, as
all 64k are buffered at the socket, then a proxy process comes in, picks
8k of data every time and sends down the wire.
2) a mod_perl process generates a response of 64k, a proxy request reads
from mod_perl socket by 8k chunks and sends down the socket, No matter
what's the client's speed the data gets buffered once again at the socket.
So even if the client is slow the proxy server completes the proxying of
64k data even before the client was able to absorb the data. Thus the
system socket serves as another buffer on the way to the client.
3) neither of them
Also if the scenario 1 is the right one and it looks like:
[ socket ]
[mod_perl] => [ ] => [mod_proxy] => wire
[ buffer ]
When the buffer size is of 64k and the generated data is 128k, is it a
shift register (pipeline) alike buffer, so every time a chunk of 8k is
picked by mod_proxy, new 8k can enter the buffer. Or no new data can enter
the buffer before it gets empty, i.e. all 64k get read by mod_proxy?
As you understand the pipeline mode provides a better performance as it
releases the heavy mod_perl process as soon as the amount of data awaiting
to be sent to the client is equal to socket buffer size + 8k. I think it's
not a shift register buffer type...
Thank you!
>
> That's the result of the discussion. I didn't tried it out myself until now
> if it really behaves this way. I will do so the next time and let you know
> if I find any different behaviour.
>
> Gerald
>
>
>
_______________________________________________________________________
Stas Bekman mailto:[EMAIL PROTECTED] http://www.stason.org/stas
Perl,CGI,Apache,Linux,Web,Java,PC http://www.stason.org/stas/TULARC
perl.apache.org modperl.sourcegarden.org perlmonth.com perl.org
single o-> + single o-+ = singlesheaven http://www.singlesheaven.com
