Hello!

On Wed, Mar 01, 2017 at 12:16:39PM -0800, Piotr Sikora via nginx-devel wrote:

> Hi Maxim,
>
> > Not sure it's good idea to don't count a 429 response as a peer
> > failure. Contrary, counting it as a failure will naturally reduce
> > load on the particular server, resulting in less rejects.
>
> But 429 can be returned on a per request basis (think client IP
> exceeding limit_req limits, or a logged in user that's rate-limited
> based on API usage), so I'd question marking backends as failed
> because of that.

Sure, but why one would use "proxy_next_upstream http_429" then?

If one of your backends reject a requests based on client's IP /
login, then you probably don't want nginx to retry such a request
on other servers, as this will just allow the user to do more
requests when you already know the limit was reached. And it
doesn't look like an effective way to build a system with
distributed limits.

In contrast, if a limit affects nginx's IP and/or group of
services on a backend, retrying on a different backend may make
sense. But use case suggests that 429 should be counted as
failure.

Note well that right now only 404 and 403 are not counted as
failures, and these are done for a very specific use case: when
only some of your backends have relevant resources available, and
404 is just used a signal to try other backends. And 403 is mostly
the same, but will appear when syncing new directories to a
backend server.

--
Maxim Dounin
http://nginx.org/
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel