<div xmlns="http://www.w3.org/1999/xhtml">Hello, Maxim!</div><div xmlns="http://www.w3.org/1999/xhtml"> </div><div xmlns="http://www.w3.org/1999/xhtml">2016 year patch seems pretty same to me  :) Interesting that I also made my patch at 2016, but we have started to use it in production a while ago (when upgraded to nginx 1.15.4 where you've fixed limit_req issue)</div><div xmlns="http://www.w3.org/1999/xhtml"> </div><div xmlns="http://www.w3.org/1999/xhtml">I think calculating excess above nodelay should be more expected behavior. Think about setting large burst and large nodelay, for ex. burst=10000 nodelay=9999. Even at relatively fast limit rate (10r/s) this will therefore lead to very large delay which I think is not expected nor by user neither by server administrator. I think it is more intuitive to think of it as you give nodelay requests for for free and additional requests with limited speed, instead of you give nodelay requests as a credit and then force client to wait all that "credited" time when he wants to make additional requests.</div><div xmlns="http://www.w3.org/1999/xhtml"> </div><div xmlns="http://www.w3.org/1999/xhtml">Also I  think it doesn't have sense to allow nodelay to be larger than burst because in any case requests that are more then burst will be rejected. May be it's better to just warn user and implicitly reduce nodelay value to burst value in that case instead of error.</div><div xmlns="http://www.w3.org/1999/xhtml"> </div><div xmlns="http://www.w3.org/1999/xhtml"> </div><div xmlns="http://www.w3.org/1999/xhtml">So I would suggest to use behavior that calculates delay based on excess above nodelay.</div><div xmlns="http://www.w3.org/1999/xhtml"> </div><div xmlns="http://www.w3.org/1999/xhtml">If you have any suggestions on fixing configuration parsing behavior or any other suggestions on my code I'm ready to make fixes.</div><div xmlns="http://www.w3.org/1999/xhtml"> </div><div xmlns="http://www.w3.org/1999/xhtml"> </div><div xmlns="http://www.w3.org/1999/xhtml">Thank you!</div><div xmlns="http://www.w3.org/1999/xhtml"> </div><div xmlns="http://www.w3.org/1999/xhtml">Peter Shchuhckin</div><div xmlns="http://www.w3.org/1999/xhtml"> </div><div xmlns="http://www.w3.org/1999/xhtml"> </div><div xmlns="http://www.w3.org/1999/xhtml">29.10.2018, 15:58, "Maxim Dounin" <mdounin@mdounin.ru>:</div><blockquote xmlns="http://www.w3.org/1999/xhtml" type="cite"><p>Hello!<br /><br />On Sun, Oct 28, 2018 at 05:58:45PM +0300, Peter Shchuchkin wrote:<br /> </p><blockquote> # HG changeset patch<br /> # User Peter Shchuchkin <<a rel="noopener noreferrer" href="mailto:peters@yandex.ru">peters@yandex.ru</a>><br /> # Date <span>1540737213 -10800</span><br /> # Sun Oct 28 17:33:33 2018 +0300<br /> # Node ID 70c0d476999d9b893c<span>644606624134248</span>ac7abad<br /> # Parent 874d47ac871a4b62fbe0ff5d469a8ad7bc5a4160<br /> Allow using nodelay=N semantics in limit_req configuration<br /><br /> This allows to use reasonably low limits while not forcing delay on normal<br /> users.<br /><br /> In addition to standard "burst=A nodelay" form now the following form of<br /> limit_req may be used:<br /> burst=A nodelay=B, where B must be 0 <= B <= burst<br /><br /> burst=A nodelay=0 means the same as just "burst=A"<br /> burst=A nodelay=A means the same as "burst=A nodelay"<br /> burst=A nodelay=B means the first B requests matching limit_zone variable will<br /> not be delayed and next requests will be delayed. The delay is calculated<br /> against excess over B thus B+1 request will have effective excess=1.<br /><br /> When using limit_req with nodelay the responsibility of limiting requests speed<br /> is on the client.<br /> If client don't want or can't correctly limit its speed it will get 503 errors<br /> and you will get numerous messages in error and access logs.<br /> When using limit_req without nodelay, then every request that comes faster then<br /> expected speed will be delayed. This is not always convenient. Sometimes you<br /> want to allow normal client to make a bunch of requests as fast as possible<br /> while still having configured limit on request speed.<br /><br /> Using this new semantics you can get the best from two worlds. Specifying<br /> burst=A nodelay=B you allow clients to make B requests without any delay (and<br /> without warnings in error log). If B requests are exceeded by client then<br /> further requests are delayed, effectively limiting client rps to desired limit<br /> without returning 503 errors. Thus one can ensure maximum speed for clients<br /> with expected usage profile and limit all other clients to certain speed<br /> without errors.</blockquote><p><br />[...]<br /><br />I've posted a patch for this a while ago, see here:<br /><br /><a rel="noopener noreferrer" href="http://mailman.nginx.org/pipermail/nginx-devel/2016-April/008136.html">http://mailman.nginx.org/pipermail/nginx-devel/2016-April/008136.html</a><br /><br />Please take a look if it works for you, and/or you have any<br />comments.<br /><br />The most noticeable difference I see is how delay is calculated, and<br />probably your variant with only counting excess above the nodelay<br />level is more logical.<br /> </p><span>--<br />Maxim Dounin<br /><a rel="noopener noreferrer" href="http://mdounin.ru/">http://mdounin.ru/</a><br />_______________________________________________<br />nginx-devel mailing list<br /><a rel="noopener noreferrer" href="mailto:nginx-devel@nginx.org">nginx-devel@nginx.org</a><br /><a rel="noopener noreferrer" href="http://mailman.nginx.org/mailman/listinfo/nginx-devel">http://mailman.nginx.org/mailman/listinfo/nginx-devel</a></span></blockquote>