>>
>> 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
_______________________________________________
nginx-devel mailing list
[email protected]
http://mailman.nginx.org/mailman/listinfo/nginx-devel
