perlbal performance

Paul Baker bakerp at google.com
Tue Oct 30 18:19:16 UTC 2007


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.







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

> So I'm giving Perlbal a taste of some production traffic, and I've
> > basically topped out at 40Mbit/s and 700req/s. [...]
> > Is this the performance level I should expect? Or am I doing something
> > wrong?
> >
>
> You have less clients in persist_wait than I'd expect, but the rest of it
> looks normal.  Running two on one box like that is fine IIRC Hyper-Threading
> is fine for this sort of application (two heavy CPU processes, but the same
> ones, so they have shared memory?).  Would be interesting to just try it
> with one process and see if you get significantly more requests through.
>
> Anyway, I seem to recall on LiveJournal we were running ~500
> requests/second through similarly configured setups before deciding to get
> more machines so as not to max out the CPUs.  Alan or somebody else might be
> able to provide more up to date numbers, but this doesn't sound too wrong.
> :)
>
> If you're concerned about the speed, it'd be worth analyzing the type of
> traffic you're sending at it, as well as the configuration you're running.
> Maximize persistent connections, especially to backend servers, etc.  Would
> have to know more about your traffic/config to give more advice here though.
>
>
>
> --
> Mark Smith / xb95
> smitty at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/perlbal/attachments/20071030/0d50598f/attachment.html


More information about the perlbal mailing list