limit proxy_next_upstream

[Weibin Yao]

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 <mdounin at mdounin.ru>

> 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 <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
>
> > _______________________________________________
> > nginx mailing list
> > nginx at nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx
>
>
> --
> 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/20130406/615dab84/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 330.gif
Type: image/gif
Size: 96 bytes
Desc: not available
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20130406/615dab84/attachment.gif>