I agree. The directive name and format are always the diffcult parts.[?] I thought we could add a new parameter to the proxy_next_upstream directive. The individual directive is OK for me.
Limit the retry total time is great. It could eliminate some very long timeout responses. 2013/4/6 Maxim Dounin <[email protected]> > Hello! > > On Fri, Apr 05, 2013 at 09:59:29PM +0800, Weibin Yao wrote: > > > We have the similar request. If we have dozens of servers in a same > > upstream block, I don't want to retry all of them. One side effect is it > > will increase the failure count with all of the backend servers. After > > several times, all of the servers will be marked down for a while and all > > of the requests will be replied with 502. > > > > We also need the retry mechnism and don't want to diable it. I think if > > there is a configurable tries time with the direcitve > proxy_next_upstream, > > it will be very nice. > > This is somewhere in TODO, and likely will be implemented soon. > As usual, the most serious problem is a name for the directive > (proxy_next_tries?). :) > > Additional similar proposal discussed here includes limiting total > time spent in retries before giving up (proxy_next_time?). This > will allow to try many servers as soon as they, e.g., return RST > quickly, but to only try one or two servers if they fail to answer > in configured proxy_connect_timeout/proxy_read_timeout. > > > > > > > 2013/4/5 Maxim Dounin <[email protected]> > > > > > Hello! > > > > > > On Fri, Apr 05, 2013 at 04:38:36AM -0400, philipp wrote: > > > > > > > Is it possible to limit the amount of upstreams asked? I have four > > > upstreams > > > > defined and it makes no sense to ask all of them. If two of them > timeout > > > or > > > > error there is possible something wrong with the request and asking > > > another > > > > node doesn't help. > > > > > > No, as of now only switching off proxy_next_upstream completely is > > > available. > > > > > > On the other hand, with switched of proxy_next_upstream you may > > > still configure retries to additional (or other) upstream servers > > > via error_page directive, using a configuration similar to last > > > example at http://nginx.org/r/error_page. > > > > > > Something like this should generate no more than two requests > > > regardless of number of upstream servers configured: > > > > > > location / { > > > error_page 502 504 = @fallback; > > > proxy_pass http://backend; > > > proxy_next_upstream off; > > > } > > > > > > location @fallback { > > > proxy_pass http://backend; > > > proxy_next_upstream off; > > > } > > > > > > -- > > > Maxim Dounin > > > http://nginx.org/en/donation.html > > > > > > _______________________________________________ > > > nginx mailing list > > > [email protected] > > > http://mailman.nginx.org/mailman/listinfo/nginx > > > > > > > > > > > -- > > Weibin Yao > > Developer @ Server Platform Team of Taobao > > > _______________________________________________ > > nginx mailing list > > [email protected] > > http://mailman.nginx.org/mailman/listinfo/nginx > > > -- > Maxim Dounin > http://nginx.org/en/donation.html > > _______________________________________________ > nginx mailing list > [email protected] > http://mailman.nginx.org/mailman/listinfo/nginx > -- Weibin Yao Developer @ Server Platform Team of Taobao
<<330.gif>>
_______________________________________________ nginx mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx
