NAME

       Perlbal::Manual::LoadBalancer - Using Perlbal as a Load Balancer

   VERSION
       Perlbal 1.78.

   DESCRIPTION
       How to configure a Perlbal Load Balancing service.

   READ ME FIRST
       Please read Perlbal::Manual::Configuration first for a better explanation on how to
       configure Perlbal. This document will make much more sense after reading that.

   Using Perlbal as a Load Balancer
       For a better understanding of how to set up Perbal as a Load Balancer, it should be noted
       that a Load Balancer and a Reverse Proxy can often be the same thing; not always, but
       often.

       A Load Balancer is a server (or device) that balances requests across a number of servers
       to spread the load. A Reverse Proxy can still do this but also have a number of other
       features.

       Perlbal as a Reverse Proxy provides features such as buffering content, preserving
       connections to the backend servers, starting connections ahead of time and a high priority
       queue, among others.

       You could almost say that a Load Balancer is a subset of a Reverse Proxy (it's not, but
       you could).

       When it comes to Perlbal, the Load Balancer is implemented as a Reverse Proxy without all
       the extra options, and that's why you set the role of a Load Balancer to "reverse_proxy":

           SET role            = reverse_proxy

       Simple load balancing

       Let's assume you want to configure two machines to serve your website and you want to let
       Perlbal decide how to balance the requests. For the sake of this exercise let's assume you
       have two servers at:

           10.0.0.1:80
           10.0.0.2:80

       And now you want to use these two machines to serve your website at:

           10.0.0.3:80

       Here's a sample configuration to make this happen:

           CREATE POOL mywebsite
               POOL mywebsite ADD 10.0.0.1:80
               POOL mywebsite ADD 10.0.0.2:80

           CREATE SERVICE service_mywebsite
               SET role            = reverse_proxy
               SET pool            = mywebsite
               SET listen          = 10.0.0.3:80
           ENABLE service_mywebsite

       The first line defines a pool of machines called "mywebsite". The second and third lines
       add your two machines to that pool (note that the indentation is not mandatory).

       After that you define a service called "service_mywebsite" with the role "reverse_proxy"
       set to listen on "10.0.0.3:80" and using the pool "mywebsite" to serve the requests.

       The last line is what allows you have several services configured in a file even if they
       are not currently active (a common scenario is to configure everything on the file and
       then enable/disable services on-the-fly as required; see Perlbal::Manual::Management for
       more information on this process).

       The Load Balancing algorithm

       Perlbal uses a highly efficient load balancing algorithm. It is very effective for
       distributing dynamic web requests among potentially heterogeneous hardware.

       First, backend servers must have their MaxClients (for apache, or equivalent) setting
       tuned to a reasonable limit. If your hardware can run 20 requests in parallel before
       running out of CPU, set MaxClients to 20.

       Next, by default Perlbal will distribute requests randomly. Opening a new connection to
       any available backend, and issuing the request.

       The proper algorithm is able to be used if "verify_backend", "backend_persist",
       "backend_persist_cache", and "connect_ahead" are enabled.

           SET persist_backend       = on
           SET verify_backend        = on
           SET backend_persist_cache = 5
           SET connect_ahead         = 2

       In this configuration, Perlbal will only route client requests to backends that it knows
       are real processes, instead of the OS listen queue. It will attempt to reuse pre-verified
       backends, and will attempt to create slightly more idle connections than it needs in
       preparation of future requests.

       When you put all this together, it becomes less likely that a client will wait for Perlbal
       to find an available backend. By setting your MaxClients properly, backends are able to
       serve traffic without getting overwhelmed. If no backends are available, Perlbal will
       queue them internally, rather than overload backends.

       You would want to disable "verify_backend" if you are balancing across image servers, or
       other extremely lightweight requests.

   SEE ALSO
       Perlbal::Manual::Configuration, Perlbal::Manual::FailOver, Perlbal::Manual::Management,
       Perlbal::Manual::ReverseProxy.