Possible limitation of ngx_http_limit_req_module

[Valentin V. Bartenev]

On Tuesday 12 May 2015 16:46:29 B.R. wrote:
> 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.

I'm agree with you.  But there are thousands "limitations" that imposed by
the algorithm used, or by the nginx internal optimizations, or by the how
hardware works.

If we will try to document every detail, then the documentation will be
over-bloated and not human readable at all.

The most detailed technical documentation is the source code itself.  So we
are trying to balance and don't turn our documentation into source code.



>    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).

Using the limit req module based on the “leaky bucket” algorithm with
the bucket size actually set to zero (i.e. burst isn't set) in most
cases is just a misconfiguration.

I'm sure in the current case it's a misconfiguration too.


>    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...

Nobody said that it cannot serve more then 1000 r/s, but you must configure
burst in this case (and actually you should in most cases).

Missing burst option usually is just a result of misunderstanding how leaky
bucket works. 


>    4. This user is maybe the first, but it is over-optimistic to consider
>    he might be alone.

Probably it's worth to be documented, but first of all let's find out if it's
really a limitation, or just misconfiguration.


> 
> 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.

nginx-devel@ archive is here: http://mailman.nginx.org/pipermail/nginx-devel/

Could you find a patch for documentation that has been discarded?

  wbr, Valentin V. Bartenev


> 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
> >