On Tue, 06 Nov 2007 13:58:35 -0500
Jim Brandt <[EMAIL PROTECTED]> wrote:
> While some of the things you mention (caching, etc.) can be a purpose
> for the reverse proxy server, the key reason is to provide a buffer
> for all of the communication bits with clients that are not related
> to processing the actual request. The front servers take the initial
> connection from the client, including potential SSL set-up then proxy
> to the back mod_perl server to handle the actual request.
>
> As soon as the back server completes the request, it moves on to the
> next. Meanwhile, the front (reverse proxy) server handles streaming
> the request back to the client which can be bound by a slow network
> connection or any number of other reasons.
>
> So caching is only one advantage of this set-up. The main goal is to
> make sure the fat processes are busy all the time and not blocking on
> something out of your control (like someone connecting via dial-up or
> mobile device).
Another thing to keep in mind when using a reverse proxy is that you
want to ensure that your ProxyReceiveBufferSize ( or the
equivalent in your proxy ) is set to be as large are your largest
XHTML page or slightly larger.
This allows the backend to push the entire page to the proxy and
truly move on to the next request. If for example you have this
set at 5K and all of your pages are 10K then the backend won't
really be able to move on until it has sent two packets to the
proxy and the client has received one of them.
-------------------------------------------------------
Frank Wiles, Revolution Systems, LLC.
Personal : [EMAIL PROTECTED] http://www.wiles.org
Work : [EMAIL PROTECTED] http://www.revsys.com
