Welcome! Log In Create A New Profile

Advanced

Re: Possible limitation of ngx_http_limit_req_module

Maxim Dounin
May 12, 2015 01:48PM
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
Subject Author Posted

Possible limitation of ngx_http_limit_req_module

jwroblewski May 11, 2015 10:59AM

Re: Possible limitation of ngx_http_limit_req_module

Valentin V. Bartenev May 12, 2015 07:34AM

Re: Possible limitation of ngx_http_limit_req_module

jwroblewski May 12, 2015 09:25AM

Re: Possible limitation of ngx_http_limit_req_module

Valentin V. Bartenev May 12, 2015 09:44AM

Re: Possible limitation of ngx_http_limit_req_module

B.R. May 12, 2015 10:48AM

Re: Possible limitation of ngx_http_limit_req_module

Valentin V. Bartenev May 12, 2015 12:30PM

Re: Possible limitation of ngx_http_limit_req_module

jwroblewski May 12, 2015 12:33PM

Re: Possible limitation of ngx_http_limit_req_module

Valentin V. Bartenev May 12, 2015 01:02PM

Re: Possible limitation of ngx_http_limit_req_module

Maxim Dounin May 12, 2015 01:48PM



Sorry, only registered users may post in this forum.

Click here to login

Online Users

Guests: 252
Record Number of Users: 8 on April 13, 2023
Record Number of Guests: 500 on July 15, 2024
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready