[PATCH] Allow using nodelay=N semantics in limit_req configuration

[Maxim Dounin]

Hello!

On Sun, Oct 28, 2018 at 05:58:45PM +0300, Peter Shchuchkin wrote:

> # HG changeset patch
> # User Peter Shchuchkin <peters at yandex.ru>
> # Date 1540737213 -10800
> #      Sun Oct 28 17:33:33 2018 +0300
> # Node ID 70c0d476999d9b893c644606624134248ac7abad
> # Parent  874d47ac871a4b62fbe0ff5d469a8ad7bc5a4160
> Allow using nodelay=N semantics in limit_req configuration
> 
> This allows to use reasonably low limits while not forcing delay on normal
> users.
> 
> In addition to standard "burst=A nodelay" form now the following form of
> limit_req may be used:
> burst=A nodelay=B, where B must be 0 <= B <= burst
> 
> burst=A nodelay=0 means the same as just "burst=A"
> burst=A nodelay=A means the same as "burst=A nodelay"
> burst=A nodelay=B means the first B requests matching limit_zone variable will
> not be delayed and next requests will be delayed. The delay is calculated
> against excess over B thus B+1 request will have effective excess=1.
> 
> When using limit_req with nodelay the responsibility of limiting requests speed
> is on the client.
> If client don't want or can't correctly limit its speed it will get 503 errors
> and you will get numerous messages in error and access logs.
> When using limit_req without nodelay, then every request that comes faster then
> expected speed will be delayed. This is not always convenient. Sometimes you
> want to allow normal client to make a bunch of requests as fast as possible
> while still having configured limit on request speed.
> 
> Using this new semantics you can get the best from two worlds. Specifying
> burst=A nodelay=B you allow clients to make B requests without any delay (and
> without warnings in error log). If B requests are exceeded by client then
> further requests are delayed, effectively limiting client rps to desired limit
> without returning 503 errors. Thus one can ensure maximum speed for clients
> with expected usage profile and limit all other clients to certain speed
> without errors.

[...]

I've posted a patch for this a while ago, see here:
 
http://mailman.nginx.org/pipermail/nginx-devel/2016-April/008136.html

Please take a look if it works for you, and/or you have any 
comments.

The most noticeable difference I see is how delay is calculated, and 
probably your variant with only counting excess above the nodelay 
level is more logical.

-- 
Maxim Dounin
http://mdounin.ru/