Is the limit_rate per tcp session or per HTTP request?

[Stefan Hellkvist]

>> 
>> Interesting! So perhaps a quick fix for my current use case would be to avoid resetting the "sent bytes” on each request? In that case the limit will be counted per socket rather than request. Probably not a generic solution that everybody would like, as it probably breaks other use cases, but perhaps something I can quickly try out on a private branch. 
> 
> That will break limit_rate.
> 
> The other peculiarity of the current implementation is that it limits
> the average rate, and the average is calculated by this formula:
> 
>    rate = bytes_sent / (current_time - request_start_time)
> 
> You may have better luck with the patch below (untested):
> 
> diff -r def9c9c9ae05 -r 9e66c0bf7efd src/http/ngx_http_write_filter_module.c
> --- a/src/http/ngx_http_write_filter_module.c   Sat Dec 12 10:32:58 2015 +0300
> +++ b/src/http/ngx_http_write_filter_module.c   Mon Dec 21 16:59:07 2015 +0300
> @@ -219,7 +219,7 @@ ngx_http_write_filter(ngx_http_request_t
>     }
> 
>     if (r->limit_rate) {
> -        if (r->limit_rate_after == 0) {
> +        if (c->requests == 1 && r->limit_rate_after == 0) {
>             r->limit_rate_after = clcf->limit_rate_after;
>         }
> 

Thanks for the patch. I tried it however and it does not seem to achieve what we want. The patch, as I understand it, only seem to make the limit_rate_after config be active on the first request in the pipeline. In our case is always a small playlist file (an HLS session starts by loading a playlist .m3u8-file) which is always less than the limit_rate_after limit that we wanted to act on the whole TCP session, so this has no affect on the larger video files that are requested after the first request in the pipeline - they will always be rate limited even the first chunks that fit under the limit_rate_after border. 

What we need is that the sent data counter and the limit_rate_after work on the TCP session and not per request and this patch does not seem to achieve that unfortunately. 

Perhaps another approach, if we do not want to touch the c->sent behaviour and keep it per request, would be to decrement the limit_rate_after with the total number of bytes sent within this TCP-session (which would mean we would have to have a separate counter for that). 

Thanks anyway. I’ll see what I can come up with…



/Stefan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20151222/00c621a9/attachment.html>