proxy_buffering off 和 limit_rate 2k同时设置时无法限速

tracymacding · 2013-11-06T11:10:29+00:00

Hello! 2013/11/2 jianyingcn: > 我们想实现不重启nginx动态编译或在&#x5...

proxy_buffering off 和 limit_rate 2k同时设置时无法限速

tracymacding

Hi，春哥

测试中发现下面两个问题：

1. 如题，这两者同时设置，limit_rate 2k无法达到限速效果；

2. 测试发现：proxy_buffering on和proxy_buffering off效率差别并不明显（客户端ab进行大文件读测试）

不得其解，求指点

agentzh

Hello!

2013/11/5 Kai Ding:
>    测试中发现下面两个问题：
>
>    1. 如题，这两者同时设置，limit_rate 2k无法达到限速效果；

是的，根据目前 Nginx upstream 的实现，在 upstream buffering （包括
proxy_buffering）禁用时，limit_rate 的设置是被忽略的。

这主要是因为 Nginx upstream 目前不会在 write event 上主动去刷下游尚未刷出去的数据，所以不能和
limit_rate 一起工作。这个问题在下面这个邮件主题里也有所提及：

    http://mailman.nginx.org/pipermail/nginx-devel/2013-October/004434.html

当使用 ngx_lua 模块产生内容并使用 ngx.flush(true) 来做严格不缓存的流式输出时，limit_rate
是可以正确工作的，因为 ngx_lua 可以正确地在每个 write event 上往外刷数据。

放开 ngx_proxy 等 upstream 模块的这个限制，需要对 upstream 进行类似的修改。

>    2. 测试发现：proxy_buffering on和proxy_buffering off效率差别并不明显（客户端ab进行大文件读测试）
>

这只对较慢速的连接效果才明显 :) 接近无限好的网络自然不容易看出差别。

Best regards,
-agentzh

tracymacding

> 2. 测试发现：proxy_buffering on和proxy_buffering off效率差别并不明显（客户端ab进行大文件读测试）

>

这只对较慢速的连接效果才明显 :) 接近无限好的网络自然不容易看出差别。

针对这个问题我也有做测试：将proxy_buffer_size设置的尽量小，2k，然后访问的文件比较大（100MB），这种情况下（proxy_buffering on & proxy_buffering off）观察发现其实效率差别也不大，我一度都在怀疑是不是我设置的proxy_buffering off没生效。

个人想法：proxy_buffering off且proxy_buffer_size为2k，那nginx每次只从后端1取2KB响应数据，而proxy_buffering on时，nginx每次从后端获取的数据应该是proxy_buffers定义的大小吧，取的次数增加了，照理说，效率应该提升的比较明显才对~

在 2013年11月6日星期三UTC+8下午12时21分05秒，agentzh写道：

Hello!

2013/11/5 Kai Ding:
> 测试中发现下面两个问题：
>
> 1. 如题，这两者同时设置，limit_rate 2k无法达到限速效果；

是的，根据目前 Nginx upstream 的实现，在 upstream buffering （包括
proxy_buffering）禁用时，limit_rate 的设置是被忽略的。

这主要是因为 Nginx upstream 目前不会在 write event 上主动去刷下游尚未刷出去的数据，所以不能和
limit_rate 一起工作。这个问题在下面这个邮件主题里也有所提及：

http://mailman.nginx.org/pipermail/nginx-devel/2013-October/004434.html

当使用 ngx_lua 模块产生内容并使用 ngx.flush(true) 来做严格不缓存的流式输出时，limit_rate
是可以正确工作的，因为 ngx_lua 可以正确地在每个 write event 上往外刷数据。

放开 ngx_proxy 等 upstream 模块的这个限制，需要对 upstream 进行类似的修改。

> 2. 测试发现：proxy_buffering on和proxy_buffering off效率差别并不明显（客户端ab进行大文件读测试）
>

这只对较慢速的连接效果才明显 :) 接近无限好的网络自然不容易看出差别。

Best regards,
-agentzh

agentzh

Hello!

2013/11/5 Kai Ding:
>
> 针对这个问题我也有做测试：将proxy_buffer_size设置的尽量小，2k，然后访问的文件比较大（100MB），这种情况下（proxy_buffering
> on & proxy_buffering off）观察发现其实效率差别也不大 ，我一度都在怀疑是不是我设置的proxy_buffering
> off没生效。

对于网络条件极好的场景，这里影响最大的“效率”其实是内存效率，而不是其他。

> 个人想法：proxy_buffering
> off且proxy_buffer_size为2k，那nginx每次只从后端1取2KB响应数据，

这种理解有问题。由于 nginx 使用的是非阻塞 IO，所以它只是在可读事件上读取当前能读的数据量。这里的 buffer size
只是规定了 nginx 从上游最多接收到这么多数据之后，如果这些数据不能及时都刷到下游去，就不再从上游读取更多数据了。这是一种通过下游写出速度来控制上游读入的速度的模式。

> 而proxy_buffering
> on时，nginx每次从后端获取的数据应该是proxy_buffers定义的大小吧，取的次数增加了，照理说，效率应该提升的比较明显才对~
>

在全缓冲模式下，上游的数据能读多少读多少，不会受下游写速度的影响。因为内存占用会明显高很多（同时有可能在超出 proxy_buffers
的大小之后，刷到临时文件，除非你把 proxy_max_temp_file_size 置为 0）。
全缓冲模式的最大意义是避免下游慢速连接影响到并发能力较弱的后端服务器，而不是提升吞吐量或者降低延时。

Best regards,
-agentzh

agentzh

Hello!

2013/11/5 Yichun Zhang (agentzh):
>
> 对于网络条件极好的场景，这里影响最大的“效率”其实是内存效率，而不是其他。
>

这里需要再补充一下。当下游速度和上游速度相同，或者下游更快时，其实 buffering on 和 buffering off
在效果上是没啥区别的，因为从上游读到的数据总是可以及时的刷到下游，不存在数据积压的问题。

这两种模式的区别体现在下游速度慢于上游速度的场合（在真实世界中是常态）。此时如何处理上游读取过快的问题，便涉及是否进行全缓冲的问题了。

为明确起见，这里说的“下游”是指浏览器或者 ab 与 nginx 之间的数据链路；而“上游”则是指 nginx 与 proxy_pass
指向的后端服务器之间的数据链路。

Regards,
-agentzh

agentzh

Hello!

2013/11/5 Yichun Zhang (agentzh):
> 这主要是因为 Nginx upstream 目前不会在 write event 上主动去刷下游尚未刷出去的数据，所以不能和
> limit_rate 一起工作。

这里值得再稍微展开一下。

由 nginx 自己的 limit_rate 机制产生的额外的“写事件”是通过 ngx_http_write_filter 函数在
r->connection->write 事件对象上面创建的定时器来产生的。所以本质上是一种伪造的“写超时”事件。这个“写超时事件”会由
c->connection->write->handler，也就是 ngx_http_request_handler 函数，触发调用
r->write_event_handler 回调。

不幸的是，ngx_proxy 等模块所依赖的基础设施 ngx_http_upstream 里面并没有让
r->write_event_handler 继续去刷输出，而是去做没什么意义的 check broken connection
之类的事情（值得一提的是，broken connection 一般触发的是读事件。我也不清楚 nginx
在这里如此处理的意图，只是觉得有些二）。

Best regards,
-agentzh

tracymacding

Hi，春哥，能指点下这部分的实现代码在哪吗？我琢磨琢磨去:)

在 2013年11月6日星期三UTC+8下午1时25分32秒，agentzh写道：

Hello!

2013/11/5 Kai Ding:
>
> 针对这个问题我也有做测试：将proxy_buffer_size设置的尽量小，2k，然后访问的文件比较大（100MB），这种情况下（proxy_buffering
> on & proxy_buffering off）观察发现其实效率差别也不大，我一度都在怀疑是不是我设置的proxy_buffering
> off没生效。

对于网络条件极好的场景，这里影响最大的“效率”其实是内存效率，而不是其他。

> 个人想法：proxy_buffering
> off且proxy_buffer_size为2k，那nginx每次只从后端1取2KB响应数据，

这种理解有问题。由于 nginx 使用的是非阻塞 IO，所以它只是在可读事件上读取当前能读的数据量。这里的 buffer size
只是规定了 nginx 从上游最多接收到这么多数据之后，如果这些数据不能及时都刷到下游去，就不再从上游读取更多数据了。这是一种通过下游写出速度来控制上游读入的速度的模式。

> 而proxy_buffering
> on时，nginx每次从后端获取的数据应该是proxy_buffers定义的大小吧，取的次数增加了，照理说，效率应该提升的比较明显才对~
>

在全缓冲模式下，上游的数据能读多少读多少，不会受下游写速度的影响。因为内存占用会明显高很多（同时有可能在超出 proxy_buffers
的大小之后，刷到临时文件，除非你把 proxy_max_temp_file_size 置为 0）。
全缓冲模式的最大意义是避免下游慢速连接影响到并发能力较弱的后端服务器，而不是提升吞吐量或者降低延时。

Best regards,
-agentzh

agentzh

Hello!

2013/11/5 Kai Ding:
> Hi，春哥，能指点下这部分的实现代码在哪吗？我琢磨琢磨去:)
>

核心逻辑基本上都在 nginx 源码树的 src/http/ngx_http_upstream.c 文件里面。上层的
src/http/modules/ngx_http_proxy_module.c 也可以同时参考一下。

Regards,
-agentzh

tracymacding

Hi,春哥，对这个问题，我仔细想想了，有如下一番理解：

以这里的配置为例，proxy_buffering off & proxy_buffer_size 2k

意味着：为该请求分配的接收缓冲区大小只有2k，如果该接收缓冲区没有被清空（写入socket发送出去），是无法再从上游socket读数据的，即便该socket通知有读事件。

这时候，nginx和上游的长连接会一直保持，占用上游服务器资源。

如果设置proxy_buffering on，只要上游socket有读事件通知，nginx就会读取响应内容，存入proxy_buffers，有可能会写disk，这样可尽快读取响应内容，释放连接，缓解上游服务器资源。

不知这种理解是否准确，或者精确~

在 2013年11月6日星期三UTC+8下午1时33分31秒，agentzh写道：

Hello!

2013/11/5 Yichun Zhang (agentzh):
>
> 对于网络条件极好的场景，这里影响最大的“效率”其实是内存效率，而不是其他。
>

这里需要再补充一下。当下游速度和上游速度相同，或者下游更快时，其实 buffering on 和 buffering off
在效果上是没啥区别的，因为从上游读到的数据总是可以及时的刷到下游，不存在数据积压的问题。

这两种模式的区别体现在下游速度慢于上游速度的场合（在真实世界中是常态）。此时如何处理上游读取过快的问题，便涉及是否进行全缓冲的问题了。

为明确起见，这里说的“下游”是指浏览器或者 ab 与 nginx 之间的数据链路；而“上游”则是指 nginx 与 proxy_pass
指向的后端服务器之间的数据链路。

Regards,
-agentzh

agentzh

Hello!

2013/11/5 Kai Ding:
> 以这里的配置为例，proxy_buffering off & proxy_buffer_size 2k
> 意味着：为该请求分配的接收缓冲区大小只有2k，如果该接收缓冲区没有被清空（写入socket发送出去），是无法再从上游socket读数据的，即便该socket通知有读事件。
> 这时候，nginx和上游的长连接会一直保持，占用上游服务器资源。
>
> 如果设置proxy_buffering
> on，只要上游socket有读事件通知，nginx就会读取响应内容，存入proxy_buffers，有可能会写disk，这样可尽快读取响应内容，释放连接，缓解上游服务器资源。
>
> 不知这种理解是否准确，或者精确~
>

对的，就是这样的 :)

Regards,
-agentzh