Hello!

On Tue, May 12, 2015 at 12:33:11PM -0400, 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 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.
>
> 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...

The "nodelay" alone will let you achieve the goal.

The "burst" should be set to a non-zero value to allow the
algorithm to tolerate peaks - that is, to tolerate cases when
several requests are processed at once.

As timekeeping in nginx uses millisecond resolution, it certainly
doesn't make sense to use burst less than expected traffic in 1ms,
20 requests in your case.

In practice, 1ms is rather optimistic - e.g., a disk seek can
easily take 10ms alone, and you'll see a 10ms burst if a request
will trigger a disk seek. As long as you want to respond within
100ms, you'll probably should tolerate bursts equal to at least
about 10ms of traffic, that is, up to 200 requests.

Note well that all the words you write about "first Y requests
during given second" imply counting requests over a _second_.
That is, it's about burst equal to expected traffic in 1 second,
20000 requests in your case.

--
Maxim Dounin
http://nginx.org/

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