Haproxy balancing - retry with another server if first timed out

We are running multiple backend servers with fastcgi protocol and we balance between them using HAproxy. Here is a sample of config:

listen Balancer 192.168.0.1:2000
    mode tcp
    option tcplog
    timeout connect 2000
    timeout server 2000
    timeout queue 2000
    timeout client 2000
    balance leastconn
    server backend1 192.168.0.2:2000 check inter 2000 rise 2 fall 5
    server backend2 192.168.0.3:2000 check inter 2000 rise 2 fall 5
    server backend3 192.168.0.4:2000 check inter 2000 rise 2 fall 5
    server backend4 192.168.0.5:2000 check inter 2000 rise 2 fall 5
    server backend5 192.168.0.6:2000 check inter 2000 rise 2 fall 5
    server backend6 192.168.0.7:2000 check inter 2000 rise 2 fall 5

The overall timeout is set to 2 seconds but most requests are handled under 0.3 seconds. The problem is that during the peaks sometimes some backend can not reply to a query under 2 seconds and then gateway timeout is returned.

What I would like to do is that when one server is selected (e.g. backend1) and it fails to deliver the reply in 1 second, HAproxy would select another backend and retry. If it fails again in 1 second then the timeout will take place.

So instead of waiting for one server for 2 seconds is it possible to wait 1 second for first, if it fails, try another and then fail?

Solution 1:

If I'm reading your question right, using setting timeout server to 1 second (1000 ms), and using option redispatch should give you the desired effect.

option redispatch
no option redispatch
Enable or disable session redistribution in case of connection failure In HTTP mode, if a server designated by a cookie is down, clients may definitely stick to it because they cannot flush the cookie, so they will not be able to access the service anymore.

Specifying "option redispatch" will allow the proxy to break their persistence and redistribute them to a working server.

It also allows to retry last connection to another server in case of multiple connection failures. Of course, it requires having "retries" set to a nonzero value.

This form is the preferred form, which replaces both the "redispatch" and "redisp" keywords.

If this option has been enabled in a "defaults" section, it can be disabled in a specific instance by prepending the "no" keyword before it.