On Tue, May 12, 2015 at 10:58:35AM -0600, Nick Couchman wrote:
> Thanks for the info, CJ. Has this feature been considered - the ability to
> add/remove on-the-fly? Anyway, I think in my situation I would just list all
> of the hosts in the config file initially and have some of them down, then I
> would already know which ones to start up to bump up the connection limit. 

Yes it's been considered a number of times but it comes with a number of
shortcomings which will affect reliability, and for most users it cannot
be traded. The first one is that the max number of FDs is automatically
determined based on the number of checks etc. This could be worked around
by implementing an extra margin to add up to X servers, with X to be
configured. The second one is that it will not be possible to use certain
LB algorithms (those based on a table) since the tables have a size based
on the PGCD of the weights of all the servers in the farm. That might be
acceptable for some users. There are a few other annoting points I don't
have in mind right now.

That doesn't mean it will not be done, just that it will not be as trivial
as it could seem and will have some limitations. But we'll work on it due
to the fact that the demand is increasing.

In the mean time, I would strongly recommend you to test the "balance first"
algorithm which packs the load on the first servers. You must configure a
maxconn value on your servers. The purpose of this mechanism is to only use
the smallest possible set of servers, allowing you to stop the other ones.
In the CSV stats there's a lastsess field saying how long ago the last
session used this server. Those remaining unused for "long enough" (threshold
to set in your monitoring scripts) can safely be turned off. And in order to
detect when to start new ones, you simply have to look at the backend queue :
once the queue grows to approx 1/2 of a maxconn, it makes sense to start a
new server. You will find that if you preconfigure your servers, you won't
even have to change your haproxy config nor to reload, the monitoring tools
will have a reliable way to take the decision to add/ remove a server and
everything will naturally follow.

> I think the use of the socket will get me most of the way toward where I want
> to go - particularly since the output comes in easily-parsable CSV. 

Absolutely :-)

Regards,
Willy


Reply via email to