Quick update: I set a really short timeout on the queue (timeout queue 100) so HAProxy returns a 503 to the 7th connection almost immediately as well. However I doubt that this is a proper solution. Any other ideas?
On Wed, Aug 2, 2017 at 2:20 PM, Claudio Kuenzler <[email protected]> wrote: > Hello guys, > > Have a question concerning a round robin balancing scenario where a > session cookie is used. > Additionally to the session cookie (and therefore re-use of the same > backend server) there is a maxconn setting of 6 per backend server, > allowing 6 concurrent connections. > > Benchmarking tests have showed that concurrent connections 7+ are being > queued. This should not happen, HAProxy should return a http error back to > the client (much like backend down). > > I thought I could tackle this with "maxqueue 1" for each backend server. > This setting works for 8+ concurrent connections; HAProxy returns a HTTP > 503 error to the client. But the 7th connection is still being queued. > > Is there a way to disable queuing at all for a backend? > > Current config: > > backend app-out > balance roundrobin > no option redispatch > cookie SERVERID insert indirect nocache > option httpchk GET /service?wsdl HTTP/1.0\r\nConnection:\ close > server app01-18383 10.10.10.11:18383 maxconn 6 maxqueue 1 cookie > 1-18383 check fall 1 rise 2 > server app01-18384 10.10.10.11:18384 maxconn 6 maxqueue 1 cookie > 1-18384 check fall 1 rise 2 > server app01-18385 10.10.10.11:18385 maxconn 6 maxqueue 1 cookie > 1-18385 check fall 1 rise 2 > server app01-18386 10.10.10.11:18386 maxconn 6 maxqueue 1 cookie > 1-18386 check fall 1 rise 2 > server app01-18387 10.10.10.11:18387 maxconn 6 maxqueue 1 cookie > 1-18387 check fall 1 rise 2 > server app01-18388 10.10.10.11:18388 maxconn 6 maxqueue 1 cookie > 1-18388 check fall 1 rise 2 > server app01-18389 10.10.10.11:18389 maxconn 6 maxqueue 1 cookie > 1-18389 check fall 1 rise 2 > server app01-18390 10.10.10.11:18390 maxconn 6 maxqueue 1 cookie > 1-18390 check fall 1 rise 2 > server app02-18383 10.10.10.12:18383 maxconn 6 maxqueue 1 cookie > 2-18383 check fall 1 rise 2 > server app02-18384 10.10.10.12:18384 maxconn 6 maxqueue 1 cookie > 2-18384 check fall 1 rise 2 > server app02-18385 10.10.10.12:18385 maxconn 6 maxqueue 1 cookie > 2-18385 check fall 1 rise 2 > server app02-18386 10.10.10.12:18386 maxconn 6 maxqueue 1 cookie > 2-18386 check fall 1 rise 2 > server app02-18387 10.10.10.12:18387 maxconn 6 maxqueue 1 cookie > 2-18387 check fall 1 rise 2 > server app02-18388 10.10.10.12:18388 maxconn 6 maxqueue 1 cookie > 2-18388 check fall 1 rise 2 > server app02-18389 10.10.10.12:18389 maxconn 6 maxqueue 1 cookie > 2-18389 check fall 1 rise 2 > server app02-18390 10.10.10.12:18390 maxconn 6 maxqueue 1 cookie > 2-18390 check fall 1 rise 2 > > Thanks, > ck > > PS: Yes, "no option redispatch" has been set on this backend. Purposely to > not redispatch to another backend server if an existing session (cookie) is > detected. For this specific application setup it's better to get a HTTP > error than to break the session. >
