O "tempo de atividade" é quanto tempo o servidor está ativo desde a última vez que o haproxy o retirou da rotação.
Portanto, se você tiver algumas verificações consecutivas acima de um determinado tempo de resposta, o tempo de atividade será redefinido.
Essas verificações são definidas pelas opções de verificação ao definir um server :
check
This option enables health checks on the server. By default, a server is always considered available. If "check" is set, the server will receive periodic health checks to ensure that it is really able to serve requests. The default address and port to send the tests to are those of the server, and the default source is the same as the one defined in the backend. It is possible to change the address using the "addr" parameter, the port using the "port" parameter, the source address using the "source" address, and the interval and timers using the "inter", "rise" and "fall" parameters.
Assim, as "poucas verificações" são controladas por:
fall <count>
The "fall" parameter states that a server will be considered as dead after <count> consecutive unsuccessful health checks. This value defaults to 3 if unspecified. See also the "check", "inter" and "rise" parameters.
O tempo de resposta ou os timers são controlados por inter :
The "inter" parameter sets the interval between two consecutive health checks to milliseconds. If left unspecified, the delay defaults to 2000 ms. It is also possible to use "fastinter" and "downinter" to optimize delays between checks depending on the server state :
Server state Interval used Up 100% (non-transitional) "inter" Transitionally up (going down) Transitionally down (going up), or yet unchecked "fastinter" if set, "inter" otherwise Down 100% (non-transitional) "downinter" if set, "inter" otherwise Just as with every other time-based parameter, they can be entered in any other explicit unit among { us, ms, s, m, h, d }. The "inter" parameter also serves as a timeout for health checks sent to servers if timeout check is not set. In order to reduce "resonance" effects when multiple servers are hosted on the same hardware, the health-checks of all servers are started with a small time offset between them. It is also possible to add some random noise in the health checks interval using the global "spread-checks" keyword. This makes sense for instance when a lot of backends use the same servers.
Mais em link .