NGINX大全 第十五章 性能调优

第十五章 性能调优

15.0 介绍

调优NGINX将使您成为艺术家。任何类型的服务器或应用程序的性能调优始终取决于许多可变项，例如但不限于环境，用例，要求和所涉及的物理组件。练习瓶颈驱动的调整是很常见的事情，这意味着要进行测试直到遇到瓶颈，确定瓶颈，调整限制，然后重复进行直到达到所需的性能要求。在本章中，我们建议在性能调优时进行测量，通过使用自动化工具进行测试并测量结果。本章还介绍了连接调优，以保持连接对客户端和上游服务器的开放性，并通过调整操作系统来提供更多连接。

15.1 使用负载驱动程序自动化测试

问题

您需要使用负载驱动程序自动化测试，为了在测试中获得一致性和可重复性。

解决方案

使用HTTP负载测试工具（例如Apache JMeter，Locust，Gatling）或您团队作为标准的工具。为您的负载测试工具创建配置，以便在Web应用程序上运行全面的测试。针对您的服务运行测试。查看从运行中收集的指标以建立基线。缓慢提高模拟用户的并发度，以模仿典型的生产使用情况并确定改进点。调优NGINX并重复此过程，直到获得所需的结果。

讨论

使用自动测试工具定义您的测试可以为您提供一致的测试，从而在调整NGINX时建立度量标准。您必须能够重复测试并衡量性能的得失，以进行科学。在对NIGNX配置进行任何调整以建立基线之前，运行测试，可以为您提供工作的基础，以便您可以衡量配置更改是否提高了性能。评估所做的每项更改将有助于您确定性能增强的来源。

15.2 保持连接对客户端开放

问题

您需要增加来自客户端的单个连接的请求的允许数量，和空闲连接允许持续存在的时间量。

解决方案

使用keepalive_requests和keepalive_timeout指令来更改可以通过单个连接发出的请求数，并且空闲连接可以保持打开的时间：

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

keepalive_requests指令默认为100，而keepalive_timeout指令默认为75秒。

讨论

通常，单个连接上的默认请求数将满足客户端的需求，因为这些天浏览器允许每个完全限定的域名打开连到单个服务器的多个连接。对域的并行开放连接的数量通常仍限制为小于10的数量，因此在这种情况下，会发生单个连接上的许多的请求。内容交付网络通常采用的一种技巧是创建指向内容服务器的多个域名，并替换代码中使用的那个域名，以使浏览器能够打开更多连接。如果前端应用程序不断轮询后端应用程序以获取更新，则这些连接优化可能会有所帮助，因为允许大量请求并保持打开状态更长时间的开放连接将限制需要建立的连接数。

15.3 保持连接向上游开放

问题

您需要保持对上游服务器的连接开放以供重用，以提高性能。

解决方案

在upstream上下文中使用keepalive指令来保持对upstream服务器的连接打开以便重用：

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工作者保持打开状态的连接的缓存。该指令表示每个工作进程保持打开状态的最大空闲连接数。upstream模块上方使用的代理模块指令对于keepalive指令为upstream服务器连接的正常运行是必需的。proxy_http_version指令指示代理模块使用HTTP版本1.1，该版本允许打开时通过单个连接发出多个请求。proxy_set_header指令指示代理模块去掉默认的关闭header，以使连接保持打开状态。

讨论

您希望保持对upstream服务器的连接的打开状态，以节省启动连接所花费的时间，从而允许工作进程转而直接通过空闲连接进行请求。请务必注意，打开的连接数可能会超过keepalive指令中指定的连接数，因为打开的连接数与空闲的连接数并不相同。keepalive连接的数量应保持足够小，以允许其他到upstream服务器的传入连接。这个小的NGINX调整技巧可以节省一些周期并提高您的性能。

15.4 缓冲响应

问题

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

解决方案

调整代理缓冲区设置以允许NGINX内存缓冲响应主体：

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

proxy_buffering指令可以是打开的或关闭的； 默认情况下它是打开的。proxy_buffer_size表示用于从代理服务器读取响应的第一部分的缓冲区的大小，具体取决于平台，默认值为4k或8k。proxy_buffers指令采用两个参数：缓冲区数和缓冲区大小。默认情况下，proxy_buffers指令设置为8个大小的4k或8k的缓冲区，具体取决于平台。proxy_busy_buffer_size指令限制了允许繁忙的缓冲区的大小，在未完全读取响应时将响应发送给客户端。默认情况下，繁忙缓冲区的大小是代理缓冲区的大小或缓冲区大小的两倍。

讨论

代理缓冲区可以极大地提高代理性能，具体取决于响应主体的典型大小。调整这些设置可能会产生不利影响，应该通过观察返回的平均body大小并进行彻底和反复的测试来进行调整。不必要时设置的超大缓冲区会耗尽NGINX的内存。您可以为特定location设置这些设置，已知这些特定location会返回较大的响应主体以获得最佳性能。

15.5 缓冲访问日志

问题

您需要对日志进行缓冲，以减少系统处于负载状态时NGINX工作进程被阻塞的机会。

解决方案

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

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

access_log指令的buffer参数表示内存缓冲区的大小，可以在写入磁盘之前用日志数据填充该缓冲区。access_log指令的flush参数设置了日志在写入磁盘之前可以保留在缓冲区中的最长时间。

讨论

将日志数据缓冲到内存中可能是优化的一小步。但是，对于要求很高的站点和应用程序，这可以对磁盘和CPU的使用情况做出有意义的调整。当对access_log指令使用buffer参数时，如果下一个日志条目不适合缓冲区，日志将被写出到磁盘。如果结合使用flush参数和buffer参数，则当缓冲区中的数据早于指定时间时，日志将写入磁盘。当以这种方式缓冲日志时，在用tail查看日志时，您可能会看到延迟，直到flush参数指定的时间。

15.6 操作系统调优

问题

您需要调整操作系统，以接受更多连接来处理高峰负载或高流量站点。

解决方案

检查内核设置中的net.core.somaxconn，这是内核可以排队等待NGINX处理的最大连接数。如果您将此数字设置为512以上，则需要在NGINX配置中将listen指令的backlog参数设置为匹配。如果您的内核日志明确要求这样做，您应该查看此内核设置。NGINX可以非常快速地处理连接，在大多数情况下，您无需更改此设置。

增加打开的文件描述符的数量是个更常见的需求。在Linux中，将为每个连接打开一个文件句柄。 因此，如果因为打开的上游连接而将NGINX用作代理或负载平衡器的话，NGINX可能会打开两个句柄。要为大量连接提供服务，您可能需要使用内核选项sys.fs.file_max来增加系统范围内的文件描述符限制，或者对于/etc/security/limits.conf文件中的NGINX正在运行的系统用户。这样做时，您还希望增加worker_connections和worker_rlimit_nofile的数量。这两个配置都是NGINX配置中的指令。

启用更多临时端口。当NGINX充当反向代理或负载平衡器时，上游的每个连接都会为返回流量打开一个临时端口。根据您的系统配置，服务器可能没有打开最大数量的临时端口。要进行检查，请检查内核设置net.ipv4.ip_local_port_range的设置。该设置是端口的上下限范围。通常可以将此内核设置从1024设置为65535。1024是已注册的TCP端口能达到的值，而65535是动态或临时端口能达到的值。请记住，您的下限应高于最高的开放侦听服务端口。

讨论

调整操作系统是您开始针对大量连接进行调整时首先会看到的地方之一。您可以针对你的特定用例对内核进行许多优化。但是，内核调整不应该一时兴起，而应该测量更改的性能表现以确保更改有所帮助。如前所述，您将知道何时开始从内核日志记录的消息中调整内核，或者何时NGINX在其错误日志中显式记录一条消息。