Reverse proxy for multiple single-threaded servers?

[Brad Fitzpatrick]

Should be fine.  Perlbal never permanently marks a node dead.

If your webserver supports it, enable persistent connections on your
internal servers (or "Keep-Alives") and hopefully your webserver also
supports OPTIONS requests.

Then, enable Perlbal's "persist_backend" and "verify_backend" options on
your configured service.

Together, that makes Perlbal never pass along a user HTTP request until it
has in its control a socket that's connected to a backend, and ALSO has
already replied to the OPTIONS request.

See, the operating system will open a TCP connection to a port, even if
there's no listener immediately available.  Your single-threaded server
might take a couple seconds to reply if it's still working on another
request.  So your operating system would've fooled Perlbal into thinking
it had a connection it could use and Perbal would've (like it used to)
send the HTTP request and just have to wait.

Nowadays Perlbal is smart enough to queue up all the HTTP requests
internally and only pass them along when it's damn sure it's got a
listener on the other end.  That's what "verify_backend" does.

Note that "persist_backend" does NOT mean users will keep going to the
same node each time, as users often want for PHP session files and such.
It means persistent CONNECTIONS only, not persistent node assignment. So
if you were using PHP sessions, you need to use a centrally-stored session
handler.

- Brad


On Fri, 22 Oct 2004, Kevin Rosenberg wrote:

> I'm thinking about using perlbal for a system running about 15
> single-threaded HTTP processes. Does perlbal handle being a proxy for
> multiple single-threaded servers okay, or might it timeout a server
> and consider it down if a the server is processing a long-running
> request and the server does not accept a new, pending request.
>
> Thanks for perlbal!
>
> Kevin
>
>