1、使用压测工具实现测试自动化

需要使用压测工具实现测试自动化，以确保测试一致性和可重复性。

使用 HTTP 压测工具，例如 Apache Jmeter、Locust、Gatling 或团队标准化的任何测试工具。为压测工具创建配置，对您的 Web 应用做全面测试，包括对服务进行测试。查看从测试中收集的指标，以建立基线。缓慢增加模拟的并发用户数，以模拟典型的生产使用情况并确定改进点。对 NGINX 进行调优并不断重复此流程，直至实现预期性能。
详解
通过使用自动化测试工具来定义测试，可通过一致的测试，构建 NGINX 调优指标。必须能够重复测试并衡量性能优劣以进行科学分析。在对 NGINX 配置进行任何调整之前，先进行测试以建立基线，这样才能衡量配置更改是否实现了性能优化。对每次更改进行衡量，有助于确定性能得以提升的根源。

2、保持客户端长连接

需要增加可在单个客户端连接上发起的请求数以及空闲连接可保持的时长。

使用 keepalive_requests 和 keepalive_timeout 指令，更改可在单个连接上发起的请求数以及空闲连接可保持打开状态的时长。

http {keepalive_requests 320; keepalive_timeout 300s;# ...
}

keepalive_requests 指令默认值为 100，keepalive_timeout 指令默认值为 75 秒。
详解
一般情况下，单个连接上的默认请求数能够满足客户端需求，因为现代浏览器能够为每台服务器（根据 FQDN）打开多个连接。与同一域名的并发开放连接数通常仍限制为小于 10，因此就这一点而言，仍会发生在单个连接上发送多个请求的情况。内容交付网络常用的 HTTP/1.1 创建多个域名指向内容服务器，并以编码的方式轮换所用域名，从而使浏览器打开更多连接。如果前端应用不断轮询后端应用以进行更新，那么这些连接优化可能会很有帮助，因为允许更多请求和保持更长时间的连接可减少需要建立的连接数量。

3、 保持上游长连接

需要保持上游（upstream）服务器长连接，以通过连接复用提高性能。

在 upstream 上下文中使用 keepalive 指令，保持上游服务器连接开放以供复用：

proxy_http_version 1.1; 
proxy_set_header Connection "";
upstream backend { server 10.0.0.42;server 10.0.2.56;keepalive 32;
}

upstream 上下文中的 keepalive 指令会为每个 NGINX worker 进程保持打开状态的连接开启高速缓存。该指令表示每个 worker 进程可保持打开状态的最大空闲连接数。在upstream 代码块上使用的代理模块指令在确保 keepalive 指令正常用于上游服务器连接方面发挥着不可或缺的作用。proxy_http_version 指令指示代理模块使用 HTTP 版本1.1，以允许在单个保持打开状态的连接上连续发送多个请求。proxy_set_header 指令指示代理模块删除默认请求头 close，以允许连接保持打开状态。
详解
需要保持上游服务器长连接，以缩短建立连接所需的时间，并允许 worker 进程直接将请求分发到空闲连接上进行处理。需要注意的是，长连接的数量可以超过 keepalive 指令中指定的连接数量，因为长连接和空闲连接并不等同。keepalive 连接数应尽量少，以允许上游服务器接受其他接入连接。该 NGINX 调优技巧可通过减少连接建立开销，提升服务器性能。

4、 响应缓冲

需要在内存中为上游服务器和客户端之间的响应启用缓冲区，以避免将响应写入临时文件。

调整代理缓冲区设置，以允许 NGINX 将响应内容写入内存缓冲区：

server {proxy_buffering on; proxy_buffer_size 8k; proxy_buffers 8 32k; proxy_busy_buffer_size 64k;# ...
}

proxy_buffering 指令的值可以是 on 或 off，默认是 on。proxy_buffer_size 表示用于读取来自代理服务器的响应首包和响应头的缓冲区大小，默认为 4K 或 8K，具体取决于平台。proxy_buffers 指令包含两个参数：缓冲区数量和缓冲区大小。默认情况下，proxy_buffers 指令被设置为 8 个缓冲区，依据平台不同单个缓冲区容量为 4k 或 8k。proxy_busy_buffer_size 指令限定了繁忙缓冲区的大小，繁忙缓冲区可支持 NGINX 在还未完全读取上游服务响应内容的情况下直接响应客户端。繁忙缓冲区的大小默认为代理缓冲区或正常缓冲区大小的两倍。如果禁用代理缓冲区，那么发生故障时，将无法把请求发送给下一台上游服务器，因为请求内容已由 NGINX 发送。
详解
代理缓冲区能显著提升代理服务性能，具体取决于响应内容的大小。调整缓冲区设置可能会产生不利影响，因此务必要参考响应消息体的平均大小并反复进行全面测试。非必要情况下不要设置过大缓冲区，因为这会占用大量的 NGINX 内存。可以只为已知会返回大型响应消息体的特定位置设置大型缓冲区，从而优化性能。
参考资料
“NGINX proxy_request_buffering 模块配置”

5、访问日志的缓冲

当系统处于高负载状态时，需要启用日志缓冲，以降低 NGINX worker 进程发生阻塞的可能性。

设置访问日志的缓冲区大小和刷新时间：

http {access_log /var/log/nginx/access.log main buffer=32k flush=1m gzip=1;
}

access_log 指令的 buffer 参数表示内存缓冲区的大小，在写入磁盘之前日志数据可保存在内存缓冲区中。access_log 指令的 flush 参数设置在写入磁盘之前，日志可保存在缓冲区中的最长时间。当使用 gzip 时，日志数据在写入日志之前会进行压缩，具有1（最快轻度压缩）到 9（最慢极限压缩）九个压缩级别。
详解
将日志数据缓冲到内存中可能只是一种很小的优化手段。但是，对于存在大量请求的站点和应用来说，这会显著影响磁盘和 CPU 的使用率。当 access_log 指令中包含buffer 参数时，如果日志条目无法再进入缓冲区，日志会直接写入磁盘。如果同时包含flush 参数和 buffer 参数，当缓冲区中的数据超过指定期限时，日志也会写入磁盘。如果跟踪日志，您可能会发现启用缓冲时，延迟可达到 flush 参数指定的时长。

6、操作系统调优

为应对尖峰负载或高流量站点，需要优化操作系统以接受更多连接。

检查 net.core.somaxconn 的内核设置，该参数表示内核可排队等待 NGINX 处理的最大连接数。如果将其设置为大于 512 的值，则需要设置 NGINX 配置中 listen 指令的 backlog 参数以进行匹配。当需要检查此内核设置时，内核日志会给予明确提示。NGINX 会非常快速地处理连接，因此对于大多数用例，无需更改此设置。

通常更需要调大可打开文件描述符（open file descriptor）上限。在 Linux 中会为每个连接打开一个文件句柄；因此，如果将 NGINX 用作代理或负载均衡器，由于需要与上游服务建立连接，NGINX 可能会为每个连接打开两个文件句柄。为了满足大量连接需求，可能需要使用内核选项 sys.fs.file_max 调大系统的文件描述符上限；而对于系统用户，NGINX 就按照 /etc/security/limits.conf 文件中的配置运行。此外，可能还需要更改 worker_connections 和 worker_rlimit_nofile 的值。它们都是 NGINX 配置中的指令。

开启更多临时端口以支持更多连接。当 NGINX 充当反向代理或负载均衡器时，每个上游连接都会为响应流量打开一个临时端口。根据系统配置，服务器可能不会将所有临时端口都打开。如要确认打开端口的数量，请查看内核设置 net.ipv4.ip_local_port_range 的设置。该设置表示所能使用的临时端口范围。通常将此内核设置设为从 1024 到 65535。1024 是 TCP 注册端口结束的位置，65535 是动态或临时端口结束的位置。请记住，下限应高于最高的开放侦听服务端口号。
详解
当为了满足大量连接需求而开始调优时，应首先优化操作系统。可以根据特定用例，对内核进行多方面的优化。但是，内核调优不应只是一时兴起，而是应根据其性能表现来衡量更改，以确保 更改有所帮助。如前所述，可以根据内核日志中记录的消息来确定何时开始优化内核，或者当 NGINX 在错误日志中给予明确提示时，开始优化内核。