nginx 网络连接相关与事件驱动模型相关的配置优化

与网络连接相关的配置

---

1.keepalive_timeout  指令

参数详解：该指令用于设置Nginx 服务器与客户端保持连接的超时时间。

这个指令支持两个选项，中间用空格隔开。第一个选项指定客户端连接保持活动超时时间，在这个之间之后，服务器会关闭此链接，第二个选项可选，其指定了使用keep-alive 消息头保持活动的有效时间，如果不设置它Nginx 服务器不会向客户端发送Kepp-Alive 消息头以保持与客户端某些浏览器的链接，超过设置的时间后，客户端就可以关闭连接，而不需要服务器关闭了。可以根据实际情况设置此值，建议从服务器的访问数量，处理速度以及网络状况方面考虑。例如，在请求大量的小文件时，保持长连接可以减少重新建立链接的次数以减轻服务器开销。如果超时时间过长的话 资源无效占用，所引发的损失将超过重新建立链接而造成的损失。以下示例仅供参考

keepalive_timeout 60 50;

该设置表示Nginx 服务器与客户端保持活动时间为60s，60s后服务器与客户端断开连接；使用keep-Alive消息头保持与客户端某些浏览器的链接时间为50s 50s后浏览器主动与服务器断开连接

---

2.send_timeout 指令

参数详解：该指令用于设置Nginx 服务器响应客户端的超时时间，这个超时时间仅针对两个客户端和服务器之间建立链接后，某次活动之间的时间，如果这个时间后客户端没有任何活动，Nginx 服务器会关闭链接，此指令的设置需要考虑服务器访问数量和网络状况等方面。下面是示例：

send_timeout 10s;

该设置表示Nginx 服务器与客户端建立链接后，某次回话当中服务器等待客户端响应超过10s，就会自动关闭链接。

---

3.client_header_buffer_size  指令

参数详解：该指令用于设置Nginx 服务器允许的客户端请求头部的缓冲区大小，默认为1KB，此指令的复制可以根据系统分页大小来设置。分页大小可以用以下命令取得：

# getconf PAGESIZE

有过Nginx 服务器工作经验的朋友可能遇到过Nginx 服务器返回400错误的情况。查找Nginx 服务器的400 错误原因比较困难，因为此错误并不是每次都会出现，出现错误的时候通常在浏览器和日志里也看不到任何小提示信息。根据部分人以往的经验来看，有很大一部分情况是客户端的请求头部过大造成的。请求头部过大，通常是客户端cooki中写入了比较大的值引起的。于是适当的增大此指令的赋值，允许Nginx服务器接收较大的请求头部，可以改善服务器对客户端的支持能力。

client_header_buffer_size 4k;

4.large_client_header_buffers 指令

参数详解：看到一片文章 里面对  3，4 两条指令有详细的测试讲解http://www.itboth.com/d/v6NnEj/nginx

---

5.multi_accept 指令

该指令用于设置Nginx 服务器时候尽可能多的接收客户端的网络连接请求，默认值为off 。

注意，设置开启的话worker_connections 设置太低可能会造成拥堵  下面会对此参数进行详解

multi_accept on;

---

与事件驱动模型相关的配置

---

1.use 指令

参数详解：use指令用于指定Nginx服务器使用的事件驱动模型

---

2.worker_connections 指令

该指令用于设置Nginx服务器的每个工作进程允许同时连接客户端的最大数量，语法为

worker_connections number;

结合worker_processes 指令，我们可以计算出Nginx 服务器允许同时练级的客户端最大数量 Client=worker_processes * worker_connections / 2 。

在看一本书的过程中看到作者 在使用Nginx服务器的过程中遇到无法访问Nginx 服务器的情况。查看日志信息发现一直报如下错误

他是怎么分析解决的呢： 

根据报错信息，推测可能是Nginx 服务器的最大访问链接数量设置小了。此指令设置的就是Nginx服务器能接受的最大访问量，其中包括前端用户链接也包括其他链接，这个值在理论上等于此指令的值与它允许开启的工作进程最大数的乘积。 此指令一般为65535；

worker_connections 65535;

此指令的赋值与linux 操作系统中进程可以打开 的文件句柄数量有关系。按照以上设置修改了赋值以后，Nginx 服务器报如下错误：

究其原因，在linux 系统中有一个系统指令open file resource limit ，它设置了进程可以打开的文件句柄数量，worker_connections 指令的赋值不能超过 open file resource limit 的赋值可以使用以下的命令查看 linux 系统中 该指令的值

#  cat  /proc/sys/fs/file-max 

可以通过下面命令将open file resource limit 指令的值设为 2390251：

# echo "2390251" > /proc/sys/fs/file-max;  sysctl -p

这样Nginx 的worker_connections 指令赋值65535 就没问题了

---

3.worker_rlimit_sigpending 指令

参数详解：该指令用于设置linux 2.6.6-mm2 版本之后的 linux 平台的事件信号队列长度上线。其语法结构为

worker_rlimit_sigpending  limit;

注：limit 为linux 平台事件信号队列的长度上限值。

该指令主要影响事件驱动模型中rtsig 模型可以保存的最大信号数。Nginx 服务器的每一个工作进程有自己的事件信号队列用于存储客户端请求发生的信号，如果超过长度上限，nginx 服务器自动转用poll 模型处理未处理的客户端请求，为了保证Nginx 服务器对客户端请求的高效处理，请大家根据实际的客户端并发请求数量和服务器运行环境能力设定该值，设置示范

worker_rlimit_sifpending 1024;

---

4.devpoll_changes 和 devpoll_events 指令

参数详解：这两个指令用于设置在 /dev/poll 事件驱动模式下，Nginx服务器可以与内核之间传递事件的数量，前者设置传递给内核的事件数量，后者设置从内核获取的事件数量，语法结构为：

devpoll_changes number;

devpoll_events number;

注：number 为要设置的数量，默认值为32.

---

5.kqueue_changes 和 kqueue_events 指令

参数详解：这两个指令用于设置在kqueue 时间驱动模式下，Nginx 服务器可以与内核之间传递事件的数量，前者设置传递给内核的事件数量，后者设置从内核获取的事件数量，其语法结构为：

kqueue_changes number;

kqueue_events number;

注：number 为要设置的数量，默认值均为512。

---

6.epoll_events 指令

参数详解：该指令用于设置在epoll 事件驱动模式下Nginx 服务器可以与内核之间传递事件的数量，与其他事件驱动模型不同，在epoll事件驱动模式下Nginx 服务器向内核传递事件的数量和从内核传递事件数量是相等得。因此没有类似epoll_changes 这样的指令,默认值为512.

epoll_events 512;

---

epoll 库 介绍

---

  epoll 库是Nginx服务器支持的高性能事件驱动库之一，它是公认的非常优秀的事件驱动模型 和poll 和select 库有很大的不同，epoll属于poll 库的一个变种，是linux2.5.44 中引入的，在linux2。6及以上的版本都可以使用它，poll库和select 库在实际工作中，最大的区别在于效率。

  他们的处理方式都是创建一个待处理事件列表，然后又把这个列表发给内核，返回的时候再去轮询检查这个列表，以判断事件是否发生，这样在描述比较多的应用中，效率就显得比较地下了，一种比较好的做法是 把描述符列表的管理交由内核负责，一旦有某种事件发生内核把发生事件的描述符列表通知进程，遮掩就避免了轮询整个描述符列表，epoll库就是这样一种模型。

  首先，epoll 库通过相关调用通知内核创建一个有N个描述符的事件列表，然后 给这些描述符设置所关注的事件，并把它添加到内核的事件列表中去，在具体的编码过程中也可以通过相关调用对事件列表中的描述符进行修改和删除。

  完成设置之后，epoll 库就开始等待内核通知事件发生了，某一事件发生后，内核将发生 事件的描述符列表上报给epoll库，得到事件列表的epoll库，就可以进行事件处理了。

 epoll 库在linux平台上是高效的，它支持一个进程打开大数目的事件描述符，上线是系统可以打开文件的最大数目；同时epoll库的IO 效率不随描述符数目增加而线性下降，因为它只会对内核上报的“”活跃“”的描述符进行操作。