Possible limitation of ngx_http_limit_req_module

[B.R.]

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
   it.
   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.
---
*B. R.*

On Tue, May 12, 2015 at 3:43 PM, Valentin V. Bartenev <vbart at nginx.com>
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
> filter
> > 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
> http://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20150512/7fdec607/attachment.html>