Possible limitation of ngx_http_limit_req_module
nginx-forum at nginx.us
Tue May 12 16:33:11 UTC 2015
Valentin V. Bartenev Wrote:
> On Tuesday 12 May 2015 09:25:05 jwroblewski wrote:
> > My use case is that upstreams are supposed to return within ~100ms,
> > therefore using burst is not an option. I wanted to use limit_req to
> > out traffic which is exceeds my backend's processing capacity, but
> > apparently it is not the right tool to use, if it only operates with
> > millisecond-precision...
> What's problem with using burst? Could you explain why it's not an
> for your case?
My nginx receives X r/s (lets assume X equals ~50000), and is supposed to
respond within 100ms to every single of them.
Requests are dispatched to upstreams, which can only handle a total of Y r/s
in a timely manner (Y being less than X, say 20000).
Knowing the capacity of my upstreams, I want nginx to *immediately* drop all
excessive requests. This means, only first Y requests which came in during
given second are to be pushed to upstreams, the remaining ones, starting
from Y+1, are to be *immediately* 503'ed.
The reason why I can not use burst, it that burst introduces queuing, which
means by the time the request leaves nginx, it is already late by some
milliseconds, while I want the whole solution to be as real time as
Having read the docs, I got the impressions that with "burst=0 nodelay" will
let me achieve the goal outlined above. Burst enables "recovery" of
excessive requests, while I want these dropped. Still, I might have gotten
the docs wrong...
> > Could you please document this limitation?
> Patches are welcome.
> But you're the only person I can remember who cares about it. For
> most of
> the users it will be just superfluous details.
I will be happy to submit a doc patch. It is possible that some users are
simply not aware of this limitation, and loose requests because of it.
> wbr, Valentin V. Bartenev
> nginx mailing list
> nginx at nginx.org
Posted at Nginx Forum: http://forum.nginx.org/read.php?2,258803,258832#msg-258832
More information about the nginx