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