perlbal performance

[Mark Smith]

>
> 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/20071031/0d83ec0e/attachment.htm