On Fri, Feb 03, 2017 at 01:35:02PM +0100, Dave Cottlehuber wrote:
> This is exactly like Zerg http://erlangonxen.org/zerg the requirements
> are that haproxy:
Just reading this made me throw up. The problem is while I can to a certain
extent imagine that for a demo, I already imagine that some people will
quickly adopt this horrible idea for production just to look smart...
> - triggers launching a new backend immediately on accepting the tcp
> handshake or ssl initiation
> - holds the frontend tcp connection open until the new backend is spun
> up
> - triggers closing the backend on close of that same connection
In fact this can be done with enough connection retries to leave enough
time for the server to start when it receives them... This is totally
disgusting.
> Maintaining a small pool of pre initialized backends might be the
> simplest way to handle this in practice.
In the past, smart people instead used to monitor the backend or server
queues and decide how many extra servers to instanciate to take the
extra load without queueing (or with a limited queue). And the "first"
balance algorithm was made exactly for this since it packs the requests
on the first servers so that as soon as the load decreases, the last
servers on the list don't receive any more traffic and can be turned
off. And the beauty in this is that the requests waiting in the queue
are immediately released when the servers become available and are
detected as such by the health checks. You just need to have at least
one server to take care of the existing requests. Note that if you
don't have any server, you can always cheat this way :
balance first
option redispatch 1
option retries 10000
server s1 1.1.1.1:80 check maxconn 10
server s2 1.1.1.2:80 check maxconn 10
server s3 1.1.1.3:80 check maxconn 10
server s4 1.1.1.4:80 check maxconn 10
...
server s100 1.1.1.100:80 check maxconn 10
server wait 255.255.255.255:80 maxconn 1
The idea is that the "wait" server always makes connections fail, causing
retries. "redispatch 1" causes a redispatch on each retry, so that every
time a connection is received without any available server, it spends one
second waiting for the "wait" server then is attempted again on another
one in case another one is available.
I think we might even have the possibility to make a little change to
set the wait server's maxconn to zero so that we don't even need the
retries nor redispatch. The main concept here still is to have the
waiting server the last of the list so that the traffic is only sent
to the other ones when they're available.
But guys, please stop inventing such horrible designs, it may make you
proud in front of your boss, but there are clueless people who adopt
them and who cause trouble they don't even understand... We end up
having to support these things and causing new trouble to the users
who are doing things correctly and who are careful about the quality
of the service they deliver to their users.
Willy
