Nginx代理缓冲 - 更改缓冲区的数量与大小？

Question

我想知道并试图找出这两个设置:

proxy_buffers [number] [size];

可能会影响(改善/降低)代理服务器的性能,以及是否更改缓冲区的大小,数量或两者......？

在我的特定情况下,我们讨论的是一个服务于动态生成的二进制文件的系统,其大小可能不同(约60 - 200kB).Nginx充当负载平衡器,在2个Tomcats面前充当发电机.我在Nginx的error.log中看到,使用默认缓冲区的大小设置,所有代理响应都缓存到文件中,因此我发现逻辑上是将设置更改为如下所示:

proxy_buffers 4 32k;

并且警告消息消失了.

我在这里不清楚的是,如果我最好设置1个较大的缓冲区,或者几个较小的缓冲区......例如:

proxy_buffers 1 128k;vs proxy_buffers 4 32k;vs proxy_buffers 8 16k;等...

可能有什么不同,以及它可能如何影响性能(如果有的话)？

Answer 1

首先，最好查看文档中有关指令的内容：

http://nginx.org/r/proxy_buffers

语法： proxy_buffers数字大小；
默认值：proxy_buffers 8 4k | 8k;
上下文：http，服务器，位置

为单个连接设置用于从代理服务器读取响应的缓冲区的数量和大小。默认情况下，缓冲区大小等于一个内存页。根据平台的不同，它可以是4K或8K。

将级别升级到http://nginx.org/r/proxy_bufferring提供了更多解释：

启用缓冲后，nginx会尽快从代理服务器收到响应，并将其保存到proxy_buffer_size和proxy_buffers指令设置的缓冲区中。如果整个响应都无法容纳到内存中，则可以将一部分响应保存到磁盘上的临时文件中。…

禁用缓冲后，响应一收到就立即同步传递到客户端。…

那么，这一切意味着什么呢？

1. 首先，对Nginx进行了高度优化，以最有效地利用资源。使用最少的资源来服务每个单独的连接是众所周知的。每个连接额外增加4KB将会是一个相当大的增长-这就是效率。

2. 您可能会注意到，缓冲区的大小被选择为等于所涉平台的页面大小。 https://en.wikipedia.org/wiki/Page_(computer_memory） 基本上，长话短说，绝对最好的数字也可能超出StackOverflow上该问题的范围，并且可能高度依赖于操作系统和CPU架构。

3. 实际上，较大数量的较小缓冲区或较小数量的较大缓冲区之间的差异可能取决于操作系统提供的内存分配器，以及您拥有的内存量和要浪费的内存量。通过分配而没有用于良好目的。

   例如，我不会将其设置为proxy_buffers 1 1024k，因为那样您将为每个缓冲的连接分配一个1MB的缓冲区，即使该内容仍然可以轻松地放入4KB的缓冲区中，也可能浪费额外的内存（尽管当然，自1980年代以来，未使用但已分配的内存实际上是免费的，鲜为人知。选择默认的缓冲区数量也是一个很好的理由8。

4. 如果实际上使用http://nginx.org/r/proxy_cache来缓存这些二进制文件的响应，则根本不增加缓冲区实际上是没有意义的，因为nginx仍将其写入磁盘以进行缓存，并且您可能也不会浪费额外的内存来缓冲这些响应。

   一个好的操作系统应该已经能够对通过文件系统缓冲区高速缓存功能写入磁盘的内容进行适当的高速缓存-请参阅https://www.tldp.org/LDP/sag/html/buffer-cache .html（以及在https://en.wikipedia.org/wiki/Page_cache上的名称有些奇怪的名称，因为HDD硬件文章已使用“ disk-buffer”名称）-因此，可能几乎不需要直接在nginx中进行重复缓冲。您还可以看看varnish-cache 关于多级缓存的一些其他想法和启发，以及良好的操作系统应该已经很好地照顾了许多事情的事实，有些人仍然尝试通过特定于应用程序的功能错误地对其进行优化。

5. 同样，如果您实际上没有缓存响应，那么您最好先问一下自己是否适合缓存。

   实际上，缓冲可能会有用，可以更好地保护您的上游免受慢速洛里斯攻击媒介的侵害-https://en.wikipedia.org/wiki/Slowloris_(computer_security ） -但是，如果您让nginx拥有兆字节大小的缓冲区，那么，从本质上讲，您将开始公开nginx本身，以消耗不合理的资源量来为具有恶意意图的客户端提供服务。

6. 如果响应太大，则可能需要考虑在响应级别对其进行优化。将某些内容拆分为单个文件；在文件级别进行压缩；使用gzipHTTP Content-Encoding级别等进行压缩

TL; DR：这确实是一个相当广泛的问题，并且有太多的变量需要进行简单的调查才能针对任何给定情况提出绝对最佳的答案。