[njs] Stream: marking incoming chain as processed.

[Dmitry Volyntsev]

details:   http://hg.nginx.org/njs/rev/647de74fd2c7
branches:  
changeset: 631:647de74fd2c7
user:  Dmitry Volyntsev 
date:  Mon Oct 29 17:36:43 2018 +0300
description:
Stream: marking incoming chain as processed.

Previously, the buffers of proxy module were not reclaimed.
This resulted in stopping the processing of new data chunks from
a client after proxy_buffer_size bytes were received.

diffstat:

 nginx/ngx_stream_js_module.c |  2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diffs (12 lines):

diff -r 72539416c466 -r 647de74fd2c7 nginx/ngx_stream_js_module.c
--- a/nginx/ngx_stream_js_module.c  Tue Oct 23 20:40:08 2018 +0300
+++ b/nginx/ngx_stream_js_module.c  Mon Oct 29 17:36:43 2018 +0300
@@ -570,6 +570,8 @@ ngx_stream_js_body_filter(ngx_stream_ses
 goto exception;
 }
 
+ctx->buf->pos = ctx->buf->last;
+
 } else {
 cl = ngx_alloc_chain_link(c->pool);
 if (cl == NULL) {
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: [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 
> # 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/
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel