view release on metacpan or  search on metacpan

README  view on Meta::CPAN

recommended that you read it using perldoc).


DESCRIPTION
-----------

Perlbal is a Perl-based reverse proxy load balancer and web server.

It processes hundreds of millions of requests a day just for LiveJournal,
TypePad and dozens of other high-traffic websites.

Perlbal is a single-threaded event-based server supporting HTTP load
balancing, web serving, and a mix of the two (see below).

Almost everything in Perlbal can be configured or reconfigured on the fly
without needing to restart the software (see Perlbal::Manual::Management).

In this file you'll find:

    * GENERAL FEATURES
    * PERFORMANCE
    * STATISTICS AND MONITORING
    * PLUGINS (EXTENSIBILITY)
    * FURTHER DOCUMENTATION
    * SUPPORT
    * CONTRIBUTING


GENERAL FEATURES
----------------

Perlbal has many features; this is just a short list of some of them:


Role: Reverse Proxy

    * Maintains pool of connected backend connections to reduce turnover

    * Gets list of nodes either from asynchronously monitored node file, or
        from in-server pool objects which you can add/remove nodes from
        using the management interface

    * Intelligent load balancing based on what backend connections are free
        for a new request. No unreliable "weighting" numbers required

    * Can verify (using a quick OPTIONS request) that a backend connection is
        talking to a webserver and not just the kernel's listen queue before
        sending client requests at it. Lower latency for the client

    * Has a high priority queue for sending requests through to backends quickly

          o Uses cookies to determine if a request should go to fast queue
            (configurable)

          o Highpri (high priority) plugin supports making requests high
            priority by URI or Host

          o Can specify a relief level to let low priority requests through to
            prevent starvation

    * Can allow X-Forwarded-For (and similar) headers from client based on
        client IP

    * Configurable header management before sending request to backend

    * Internal redirection to file or URL(s)

          o Big one for us; a backend can instruct Perlbal to fetch the user's
            data from a completely separate server and port and URL, 100%
            transparent to the user

          o Can actually give Perlbal a list of URLs to try. Perlbal will find
            one that's alive. Again, the end user sees no redirects happening

          o Can also redirect to a local file, which Perlbal will serve
            non-blocking. See webserver mode below

    * Persistent client connections (configurable)

    * Persistent backend connections (shared by multiple clients;
        no "backend waste") 


Role: Web Server

    * Listen on a port, share from a directory

    * Directory indexing

    * Byte range support (clients can resume downloads)

    * Can have directory index requests fall back to index file list

          o I.e., requests for /foo/ go to /foo/index.html instead

          o Multiple index files supported, tries one at a time until it finds
            one

    * Persistent client connections (configurable)

    * Almost all disk operations are done asynchronously as to not stall the
    event loop

    * Configurable support for storing files (PUT, DELETE support)


PERFORMANCE
-------------

    * Great performance "out-of-the-box" (for both small and large sites)

    * 100% asynchronous in all the recommended use cases

    * Lightweight

    * HTTP Header processing (optionally) done in C with
        Perlbal::XS::HTTPHeaders for maximum performance

    * Event-based using epoll or kqueue to avoid the scalability problems of
        not-so-modern systems