Possible to have a limit_req "nodelay burst" option?

[Richard Stanway]

On Mon, Apr 15, 2013 at 6:38 PM, Maxim Dounin <mdounin at mdounin.ru> wrote:
>
> Hello!
>
> On Mon, Apr 15, 2013 at 06:18:04PM -0400, Richard Stanway wrote:
>
> > Hello,
> > I'm using the limit_req directive to control the rate at which my backends
> > are hit with requests. Typically a backend will generate a page and the
> > client will not request anything for a short while, so a rate of 1 per
> > second works well. Sometimes however a backend will return a HTTP redirect,
> > and then the client must wait for a one second delay on the request to the
> > redirected page. I'd like to avoid this if possible to avoid the slow
> > feeling when users click on redirected links.
> >
> > The nodelay option looked like it would work at first glance, but this
> > bypasses the delay completely for all requests up to the burst, so it's
> > still possible for the backend to be hit with many requests at once.
> > Ideally I would like to have a "nodelay burst" option to control how many
> > of the burst requests are processed without delay which I could set to 2 in
> > my situation, while still delaying any further requests beyond that.
>
> ... and next time you'll notice that site feels slow on a page
> which uses 2 redirects in a row, or includes an image/css from a
> backend, or user just clicks links fast enough.
>
> I would recommend just using "limit_req ... nodelay" unless you
> are really sure you need a delay in a particular case.

Thanks for the reply. I'll try to explain my situation a little
better, the delay is mainly there to prevent crazy scripts / spambots
/ etc from making too many fast requests to the backend and tying up
the "expensive" processes. Images and CSS are served from a separate
backend that isn't subject to rate limiting, and if the main backend
determines a redirect is needed, it will guarantee a redirect to a
final URL with no further intermediate redirects.

Currently I'm using a burst of 10 since showing a 503 to users is a
bad experience, in the event they click links really fast I'd prefer
them to just think the server is a little busy. I was hoping to remove
this delay on redirects or at least the first couple of "fast clicks",
while still causing spambots / etc to be subjected to 1 req/s delay so
the backend is not suddenly hit with up to 10 requests at once. For
now I'm going to try using rewrite rules to catch the most commonly
redirected paths and pass them to a non-limited backend, but I'd
really like to see this feature if possible.

Regards,
Richard