Error handling of "Connection refused" conditions
Dustin Wenz
dustinwenz at ebureau.com
Wed Jun 20 19:40:52 UTC 2012
This is how an affected service is configured. We have our proxy_read_timeout set high, because some requests can legitimately take that long to return. Any other timeouts would be the default; presumably 60 seconds.
upstream pool012 {
server 172.16.1.223:80;
server 172.16.1.224:80;
server 172.16.1.225:80;
server 172.16.1.226:80;
server 172.16.1.227:80;
}
keepalive_timeout 65;
server {
listen 172.16.6.103:80;
server_name application012.domain.com;
error_log logs/application012.error.log ;
location / {
proxy_pass http://pool012;
proxy_next_upstream error timeout invalid_header http_500 http_502 http_503;
proxy_redirect off;
proxy_read_timeout 930s;
}
}
Is it considered good practice to reduce proxy_connect_timeout to some small value if responsiveness during an outage is desired?
- .Dustin
On Jun 20, 2012, at 2:04 PM, Reinis Rozitis wrote:
>> I am using nginx to distribute http load across three upstream application servers. It actually works really well in normal usage, but when we restart one of the upstream servers for maintenance (such as for an OS update), nginx tends to hang incoming requests for some time (30 seconds or more). When a node is brought offline, the nginx error logs show a few messages like this:
>
>
> You should probably post the relevant parts of your configuration since there are quite few parameters to tune nginx for a better responsiveness.
>
> To name a few: proxy_connect_timeout, proxy_read_timeout, proxy_send_timeout which by default are 60 seconds (what could explain your "hanging" requests), lowering those allows 'proxy_next_upstream' (by default - timeout and error) kick in sooner so the backend changes/restarts are seemless and don't really affect the end-users so much.
>
> rr
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
More information about the nginx
mailing list