Possible limitation of ngx_http_limit_req_module
reallfqq-nginx at yahoo.fr
Tue May 12 14:46:29 UTC 2015
I do not necessarily have a say on what is discussed here, but:
1. I believe putting known limitations in the docs makes sense. Who
defined the docs as sticking to the most common use cases? Technical docs
are technical docs.
2. Using burst answers a specific need which has not been expressed here
(on the contrary I think it is mandatory such a behavior does not happen in
this use case).
3. Awaiting nginx to serve more than 1000 r/s is reasonable for a Web
server claiming to scale and having been designed for HA. Silently ignoring
extra requests per millisecond is awful, especially if no-one knows about
The users are not supposed to guess by themselves that using requests
limiting will make their availability silently drop...
4. This user is maybe the first, but it is over-optimistic to consider
he might be alone.
It could be interesting to know if you discarded documenting some other
known limitations in your product(s), deciding on the behalf of the users
what they should/need to know or not.
On Tue, May 12, 2015 at 3:43 PM, Valentin V. Bartenev <vbart at nginx.com>
> 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 option
> for your case?
> > 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.
> wbr, Valentin V. Bartenev
> nginx mailing list
> nginx at nginx.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the nginx