perlbal performance

Paul Baker bakerp at google.com
Wed Oct 31 01:47:43 UTC 2007


Thanks for the advice. I dropped my connect_ahead down to 10 and left
backend_persist_cache at 20. CPU usage seems to have dropped about 10-20%.

I don't have perlbal serving any static resources yet. Since only some
servers are behind Perlbal, we haven't made any application changes yet to
make better use of Perlbal but that is definitely something I'll be checking
out. One thing I'm confused about though in regards to the static serving,
is the whole Linux::AIO vs IO::AIO thing. Is one better than the other? Or
are they actually the same thing? I have IO::AIO installed, but basically
being unused so far since Perlbal is not serving any static content.

On Oct 30, 2007 7:42 PM, Mark Smith <smitty at gmail.com> wrote:

> The states output is from only one perlbal instance, so the real numbers
> > are basically double that. Here is my basic config:
> >
> > CREATE SERVICE feeds
> >   SET role                  = reverse_proxy
> >   SET pool                  = feedspool
> >   SET persist_client        = on
> >   SET persist_backend       = on
> >   SET verify_backend        = on
> >   SET connect_ahead         = 50
> >   SET enable_error_retries  = on
> >   SET backend_persist_cache = 20
> >   SET balance_method        = random
> > ENABLE feeds
> >
> > I have my backends configured to handle 275 threads each (which if they
> > actually did serve that many at once would explode) because I haven't really
> > optimized that number for "the perlbal way". Perlbal has yet to actually
> > connect that many to a backend by a long shot. Does it make sense for me to
> > go with a large connect_ahead and/or backend_persist_cache? I'm still a bit
> > unclear on what specifically each does? Or should I stick with the numbers I
> > have? Should they be the same number? I figured that setting it high would
> > just waste more cpu cycles if Perlbal is constantly iterating through a
> > bunch of bored connections deciding whether to keep them connected or not.
>
>
> Briefly, connect_ahead instructs Perlbal to pre-load connection creation
> and backend verification.  It starts the process even if it doesn't have any
> requests, and it keeps the process going so you have this many bored
> backends (well, it tries).  The backend_persist_cache is how many bored
> backends can sit around before being killed off.
>
> Your connect_ahead is definitely too high IMO.  Unless you're expecting
> huge spikes of traffic where it's vitally important for you to shave off the
> time it takes Perlbal to handshake and verify a new backend connection, that
> many pre-started connections doesn't really help anything and just serves to
> take up cycles.  Unless you really think you need to save that startup time,
> this can be turned off completely or set to a low value of 3-5.
>
> The backend_persist_cache is good to keep at some level in order to allow
> persistent backend connections to survive short lulls in traffic.   Your 20
> seems a reasonable number, I've used lower in the past, but it doesn't
> really matter that much.  This doesn't create extra work for Perlbal, it
> just defines how much work it is allowed to get rid of, banking on not
> needing those surplussed backend connections right away.
>
> Neither of these tweaks will really change the general performance values
> of Perlbal though.  If you're running XS headers and not doing anything
> special with custom plugins, I don't think there's too much more you can do
> to speed it up.  Perhaps if you are serving static files by your backends
> and not by Perlbal, you could consider moving them to the Perlbal machines.
> It takes less CPU to do a local sendfile than a reverse proxy operation.
> (But then, I seem to recall your states output indicated you're already
> doing local file serving on the Perlbals...)
>
>
>
> --
> Mark Smith / xb95
> smitty at gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/perlbal/attachments/20071030/7dc767cb/attachment.html


More information about the perlbal mailing list