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
