Fwd: fair load balancing?
dormando at rydia.net
Mon Jun 23 21:50:13 UTC 2008
> As an observer, his thread has been helpful for my thinking, but there
> are still a few details I'm unclear about. Particularly, assuming I
> have persistent connections to both the client and the backend, what
> happens at the end of a request?
> Do the particular client and particular backend remain associated for
> multiple requests, or does the backend go back into the pool? Is the
> Options request sent once per client, once per backend, or once per
Backend goes back to the pool. Options request is sent once per
established backend connection; so if you connect to a backend and reuse
it 500 times, you'd have one OPTIONS request and 500 normal requests.
> The use case I'm considering involves two levels of Perlbal for a
> distributed search engine. An application makes a request to the a
> front end search server, which in turn makes parallel requests via a
> custom plugin to a dozen or so backend search servers. The backend
> servers act as standard reverse proxies to a small fixed number of
> local processes.
> I'd like to be able to run two front end search servers for
> redundancy, each with multiple persistent connections to each of the
> back end servers. I'm worried that if one front end server
> temporarily goes down, the other might end up hogging all the
> processes. I think that if the backends go back into the pool after
> each request I'm safe, but that if the clients remain associated I'll
> have problems. How does it actually work?
That happens with any pooled perlbal setup... You want to tune how long
a backend is used before being recycled. If you're really worried and
get about 5 hits per second, you might set the max backend uses to 10.
So if you have perlbals A and B. A goes down, B hogs all of the
connections, and A starts up again, A gets client traffic, starts
opening new backend requests, and will "win" them slowly as B gives up
backends, until it's more or less even.
More information about the perlbal