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

Question

我想知道并试图弄清楚这两种设置如何：

proxy_buffers [number] [size];

可能会影响（提高/降低）代理服务器性能，以及是否更改缓冲区的大小或数量，或两者兼而有之...？

在我的特殊情况下，我们讨论的是一个系统，它提供动态生成的二进制文件，其大小可能会有所不同（~60 - 200kB）。 Nginx 在 2 个充当生成器的 Tomcat 前充当负载均衡器。我在 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 的缓冲区，这可能会浪费额外的内存 (@987654324 @)。缓冲区的默认数量也被选为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 硬件文章已经使用了“磁盘缓冲区”名称）——因此，可能几乎不需要直接在 nginx 中复制缓冲。您还可以查看varnish-cache，以获取有关多级缓存主题的一些其他想法和灵感，以及良好的操作系统已经应该照顾好一些人仍然试图错误地尝试的许多事情这一事实通过特定于应用程序的功能进行优化。

5. 同样，如果您实际上不缓存响应，那么您不妨先问问自己缓冲是否合适。

   实际上，缓冲可能有助于更好地保护您的上游免受 slowloris 攻击向量 - https://en.wikipedia.org/wiki/Slowloris_(computer_security) - 但是，如果您确实让您的 nginx 拥有兆字节大小的缓冲区，那么，本质上，您开始暴露 nginx 本身消耗不合理的资源来为具有恶意意图的客户提供服务。

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

---

TL;DR：这确实是一个相当广泛的问题，而且有太多的变量需要不平凡的调查才能得出任何给定情况的绝对最佳答案。