> On May 18, 2017, at May 18, 2:58 AM, Jiafan Zhou <[email protected]> > wrote: > > Hi Bryan, > > For reference: > > >> defaults >> timeout http-request 10s >> timeout queue 1m >> timeout connect 10s >> timeout client 1m >> timeout server 1m >> timeout http-keep-alive 10s >> timeout check 10s >> > > - For "timeout check" and "inter", it was for some troubleshooting and would > like to understand the behaviour a bit more. By reading haproxy official > document, it is not clear to me. > > I think in my case, it uses the "timeout check" as 10 seconds. There is no > "inter" parameter in the configuration. > >
Ten seconds for a health check to respond is an eternity. Personally, I’d expect a response 1000 times faster than that. Why do you want it to be so long? What problems with the default health check was this super long timeout meant to resolve? > But here I try to understand which value will use if "timeout check" is > present, but "inter" is not. I already set the timeout check". > > - Finally, I think I am still right about the "fall" (default to 3) and > "rise" (default to 2). > > It takes up to 50 seconds to converge the server, as far as the haproxy is > concerned. > > I don’t think that health checks are run concurrently to the same server in a backend. This means that if your server is accepting the TCP connection but not responding before the “timeout check” timer strikes, then you could be seeing 40+ second times to detect the failure especially if there are delays in making the connection for the healthcheck too. The defaults should detect a down server in 3 consecutive failures with 2 seconds between each check so 6 seconds or so. -Bryan
