Grokbase
Topics Posts Groups | in
x
[ help ]

Re: perlbal performance

View Post | Saved ByFlat  Thread  Threaded | < Prev - Next >
Paul Baker Re: perlbal performance
| +2 votes
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]

Thread : perlbal performance
1)
Paul Baker So I'm giving Perlbal a taste of some production traffic, and I've basically topped out at 40Mbit/s...
2)
Mark Smith You have less clients in persist_wait than I'd expect, but the rest of it looks normal. Running two...
3)
Paul Baker The states output is from only one perlbal instance, so the real numbers are basically double that....
4)
Mark Smith Wow, that's far more than I expected! Good to know. :) I don't have perlbal serving any static...
5)
Andrew Sweger I finally have an excuse to actually use perlbal. I used 1.60 to build debs using the provided...
paperclip
spacer
View Post | Saved ByFlat  Thread  Threaded | < Prev - Next >
Home > Groups > Perlbal > perlbal performance (5 posts) > View Post