Nginx服务器性能优化的三大方面

Nginx服务器非常快，但是Nginx的默认设置并没有针对具体的硬件进行调优。在这篇文章中，我们要把Nginx的性能发挥到极限。Nginx的配置分为三大部分：worker进程配置、I/O配置、TCP配置。我们将分别对这三大配置展开讨论，并在最后给出综合性的配置。

1.Nginx的worker进程配置

worker_processes

worker_processes directive指定nginx worker进程的数量。它是一个全局性配置，不属于events模块，也不属于http或location模块。

worker_processes 1;

默认的值是1，意味着nignx只打开一个worker进程。最优的设置是worker进程数量要与CPU的核数相等。我们可以用lscpu命令来找出CPU的核数。

lscpu

也可以用

cat /proc/cpuinfo | grep 'processor' | wc -l

另外，我们也可以将worker_processes的值设为auto，这样nginx会自动检测CPU核数并打开相同数量的worker进程。

当nginx添加了SSL证书时，最好要打开多个worker进程。SSL握手会进行硬盘I/O操作。所以打开多个worker进程有利于性能的提升。

accept_mutex

当我们为nginx打开了多个worker进程后，我们需要配置如何选择worker进程来完成相应的请求处理。在events模块中，我们可以设置

events {
 accept_mutex on;
 }

accept_mutex会轮流来选择worker进程。Nginx默认开启了accept_mutex。

如果accept_mutex的值被设为off，那么当有请求需要处理时，所有的worker进程都会从waiting状态中唤醒，但是只有一个worker进程能处理请求，这造成了thundering herd现象，这个现象每一秒钟会发生多次。它使服务器的性能下降，因为所有被唤醒的worker进程在重新进入waiting状态前会占用一段CPU时间。

accept_mutex_delay

当accept_mutex功能启用后，只有一个持有mutex锁的worker进程会接受并处理请求，其他worker进程等待。accept_mutex_delay指定的时间就是这些worker进程的等待时间，过了等待时间下一个worker进程便取得mutex锁，处理请求。accept_mutex_delay在events模块中指定，默认的值为500ms。

events {
 accept_mutex_delay 500ms;
 }

worker_connections

worker_connections的默认值是512,它在events模块中。它指定了一个worker进程在同一时间可以处理的最大请求数。

events {
 worker_connections 512;
 }

将它的值增加到1024左右。

web服务器同时处理的请求数并不等于它同时服务的客户端数量。一个浏览器会打开多个并发连接来下载网页的各个部分，如图片、脚本等等。而且不同的浏览器对同一个网页打开的并发连接数量也会有所不同。

worker_rlimit_nofile

由于每一个socket都会打开一个文件描述符，所以服务器可以同时处理连接数量受到系统文件描述符数量的限制。如果nginx打开的socket数量超过了文件描述符的数量，那么在error.log文件中会出现too many opened files错误。我们可以用下面的命令来查看文件描述符的数量：

$ ulimit -n

Nginx worker进程默认的用户名是www-data，用户www-data所拥有的文件描述符的数量要大于worker进程数量与worker_connections之乘积。nginx有一个worker_rlimit_nofile directive，可以用来设置系统可用的文件描述符。这与ulimit设置可用文件描述符的作用是一样的。如果它们都设置了可用文件描述符，那么worker_rlimit_nofile会覆盖ulimit的设置。

worker_rlimit_nofile 20960;

查看操作系统对一个进程施加的限制，我们可以用命令读取/etc/$pid/limits文件，$pid是进程的pid。

multi_accept

multi_accept可以让nginx worker进程尽可能多地接受请求。它的作用是让worker进程一次性地接受监听队列里的所有请求，然后处理。如果multi_accept的值设为off，那么worker进程必须一个一个地接受监听队列里的请求。

events {
 multi_accept on;
 }

默认Nginx没有开启multi_accept。

如果web服务器面对的是一个持续的请求流，那么启用multi_accept可能会造成worker进程一次接受的请求大于worker_connections指定可以接受的请求数。这就是overflow，这个overflow会造成性能损失，overflow这部分的请求不会受到处理。

use

Nginx处理请求的方法有很多种，每一个方法都允许Nginx Worker进程监测多个socket文件描述符。这些方法都分别依赖于特定的平台，用于生成Nginx二进制文件的configure命令会选择适合当前平台的最有效的方法。如果要使用另外的方法，那么我们必须先启用这些方法。

我们可以用use这个directive来选择另外的处理请求的方法。use directive属于events模块。

events {
 use select;
 }

Nginx支持以下请求处理方法：

• select: 这是一种标准的请求处理方法。如果一个平台上缺少相应的更加有效的方法，那么Nginx会自动使用select方法。

• poll: 这是一种标准的请求处理方法。如果一个平台上缺少相应的更加有效的方法，那么Nginx会自动使用poll方法。

• kqueue: 这是BSD家族操作系统上可用的一种高效的请求处理方法。可用于FreeBSD, OpenBSD, NetBSD和OS X。kqueue方法会忽略multi_accept。

• epoll: 这是Linux系统上可用的一种高效的请求处理方法，类似于kqueue。它有一个额外的directive，那就是epoll_events。epoll_events指定了Nginx可以向内核传递的事件数量。默认的值是512。

2.Nginx的I/O配置

sendfile