On Tuesday 12 May 2015 12:33:11 jwroblewski wrote:
> 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
> > 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?
>
> 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 problem that there's no given second in the leaky bucket algorithm and
the *immediately* doesn't a technical term, since there's nothing happens
immediately. The "immediately" has some measurable time.

For example setting rate=10r/s literally means every request that comes earlier
than 100ms after the previous will be discarded. Even if a client have made
only 100 requests but within 100 ms interval then 99 will be discarded.

To allow bursts in request rate (bursts are natural and they always exist
in normal http traffic) the burst parameter must be configured.


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

No, it doesn't introduce any delays or queuing if you have the "nodelay" option
set (btw, "nodelay" actually does nothing without the burst set).

You should try something like:

limit_req zone=test_zone burst=100 nodelay;

Even burst=5 will let limit req with rate=5000r/s to behave in your tests as you
expected.

wbr, Valentin V. Bartenev



>
> 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@nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx
>
> Posted at Nginx Forum: http://forum.nginx.org/read.php?2,258803,258832#msg-258832
>
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx