limit proxy_next_upstream

Weibin Yao yaoweibin at gmail.com
Fri Apr 5 13:59:29 UTC 2013


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.


2013/4/5 Maxim Dounin <mdounin at mdounin.ru>

> 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
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>



-- 
Weibin Yao
Developer @ Server Platform Team of Taobao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20130405/b3dac770/attachment.html>


More information about the nginx mailing list