Grokbase
Topics Posts Groups | in
x
[ help ]

Posts > balancer

Tagged Posts: balancer
Paul Baker Re: perlbal performance
| +2 votes
The states output is from only one perlbal instance, so the real numbers are basically double that....
Perlbal
saved to perlbal balancer load performance by 1 person
[ Profile | Reply to group ] [ Flat  Thread  Threaded ]
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@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
> [email protected: s...@gmail.com]
spacer
Tagged Posts: balancer
Home > Posts > Tags > balancer