查看“Nginx代理模块缓冲指令”的源代码

[[File:nginx-cache-1.jpg|500px|center|border]]

在使用代理时最重要的因素是性能。默认情况下，Nginx会在返回响应给客户端之前，尽可能快、尽可能多地从上游服务器尝试读取。代理会尽可能地将响应缓冲在本地一次性全部投递给客户。如果来自于客户的请求或者是从上游服务器的响应的任何部分被写到磁盘上，那么性能可能会降低。这需要内存和硬盘之间进行权衡，因此在Nginx作为反向代理时考虑表中的指令非常重要。

[[File:nginx-cache-2.jpg|500px|center|border]]

除了前面的指令，可能由于上游服务器设置x-accel-buffering头影响了缓冲。该指令的默认值为yes，意味着响应被缓冲。设置为no，则对Comet和Http流应用程序有用，这类响应没有缓冲很重要。

通过测量经过反向代理的平均请求和响应的大小，代理缓冲区的大小可以被调整到最佳使用状态。一个缓冲指令统计除了操作系统相关的每个连接的开销，因此我们能够计算出我们的系统能够同时有多少个客户端连接。

proxy_buffers指令的默认值（8个4KB或者8个8KB，依赖于具体的操作系统）能够接受一个大的并发连接数。我们来弄清楚能有多少连接数。在一个典型的 1GB 内存机器上，该机器上只有Nginx在运行，大多数内存都由它使用，一些内存由操作系统的文件系统缓存或者其他使用，所以保守地估计 Nginx 能够使用的内存到达768MB。
8个4KB 的缓冲是32768字节（8 * 4 * 1024）每个活动的连接。

能够分配给Nginx的内存768 MB是805306368字节（768 * 1024 * 1024）。

除以2，达到805306368 / 32768 = 24576个活动连接。

因此，在默认的配置中，假设这些缓冲被持续填满，那么Nginx能够同时处理约25000个连接。还有一些其他的因素发挥作用，如缓存的内容和空闲的连接，但是只是给出了一个粗略的工作情况。

现在，如果采用下面的数值作为的平均请求和响应大小，看到8个4 KB的缓冲不足以处理典型的请求，想让Nginx缓冲尽可能多的响应以便用户一次接收到，提供给用户一个快速的链接。

◆ 平均请求的大小：800 bytes。

◆ 平均响应的大小：900 KB。
 
在本办法中调优的例子将会使用更多的内存，以便满足并发活动连接可使用更多的资源。它们只是优化，而不能作为一个通用配置来理解。对于多、慢的客户端，少、快的上游服务器来说，Nginx已经进行了优化。在这个计算机时代下，更多的是移动用户，这些客户端连接比宽带用户更加慢，因此，在优化之前最重要的是要知道他们如何连接。

将相应地调整缓冲大小，以便整个响应都容纳在缓冲中。

 http {
 proxy_buffers 30 32k;
 }
当然，这意味着我们只能处理较少的并发用户。

30个32 KB 缓冲是983040字节（30 * 32 * 1024）每个连接。

768 MB 分配给Nginx就是805306368字节（768 * 1024 * 1024）。

除以2，达到805306368 / 983040 = 819.2个活动连接。

如果没有太多的并发连接，我们可以将缓冲的数量向下调整，以便确保Nginx在传输的过程中将响应的剩余部分读到proxy_buffers剩余空间中。
 http {
 proxy_buffers 4 32k;
 proxy_busy_buffers_size 64k;
 }
4个32KB的缓冲是131072（4 * 32 * 1024）字节每个连接。

将768 MB分配给Nginx是805306368字节（768 * 1024 * 1024），除以 2，能够到达805306368 / 131072 = 6144个活动连接。对于反向代理机器，可能想扩展更多的内存（6GB将能够产生约37000的连接），或者在负载均衡器后面的机器上添加1GB的内存以达到预期的并发数量。