2
  • If the port of my upstream's backend is closed, usually nginx fail very quickly and try the other backend, in the error log I can see

connect() failed (111: Connection refused) while connecting to upstream

  • If my upstream's backend is down and there is no route to the host, nginx fail very slowly (~3 seconds) and causing delay in term of user experience, and in the error log I can see

connect() failed (113: No route to host) while connecting to upstream

So, it is possible to reduce the 3 seconds delay when nginx found out that the backend is not available?

MadHatter
  • 78,442
  • 20
  • 178
  • 229
Ryan
  • 5,341
  • 21
  • 71
  • 87
  • 1
    Did you try setting proxy_connect_timeout to lower values? – Andrei Mikhaltsov May 31 '13 at 12:49
  • @AndreiMikhaltsov, the `proxy_connect_timeout` is irrelevant as it is default to `60s`, but from my test, during the host not found situation, the timeout is around `3s` – Ryan Jun 01 '13 at 02:20
  • You might be hitting a TCP parameter, not an nginx setting. Take a look at http://serverfault.com/questions/295390/how-can-i-tune-the-initial-tcp-retransmit-timeout (tl;dr the 3 second timeout is built into the kernel) – cjc Jun 05 '13 at 18:11

1 Answers1

1

The answer is NO. This is system timeout for allow routers decide that destination is unreachable for your machine.

But you can write service-prober (if your backends are known), which will probe services and if make embedded OS firewall answer instantly with ICMP host-unreachable message through iptables or ipfw.

madlynx
  • 171
  • 2