Hi, Willy On 16/06/17 12:15, Willy Tarreau wrote:
So I have more info on this now. Veiko, first, I'm assuming that your config was using "resolvers dns_resolvers" on the "server" line, otherwise resolvers are not used.
My real world configs use resolvers, but timeouts happen even when resolver was not used anywhere. It is why I did not include resolvers in the example config backend server provided with initial report e-mail. When keeping only single server under resolvers section, I did not notice any timeouts. And it did not matter whether that single server was local or Google.
What I've seen when running your config here is that google responds both in IPv4 and IPv6. And depending on your local network settings, if you can't reach them over IPv6 after the address was updated, your connection might get stuck waiting for the connect timeout to strike (10s in your conf, multiplied by the number of retries). The way to address this is to add "resolve-prefer ipv4" at the end of your server line, it will always pick IPv4 addresses only.
We have 'resolve-prefer ipv4' enabled in real world configuration when resolver is used actually on 'server' line. We have disabled IPv6 for all our servers. Anyway - since timeouts happen even without using resolver anywhere, this must not be the cause of timeouts.
BTW, (probably that it was just for illustration purpose), but please don't use well-known services like google, yahoo or whatever for health checks. If everyone does this, it will add a huge useless load to their servers.
It was just that anybody could use simple trimmed down configuration for quick testing. Real configuration has no need for having google.com as backend and is much more complex.
This exact configuration can be easily used to test 1.6.12 - a simple reload would cause two first google.com checks to fail with timouts. Also any requests against ssl-frontend will fail few first checks after reload.
Regards, Veiko
