Nginx的优化配置

user root root;

默认用户是nobody，如果nginx需要访问某些比如root类权限的文件，会提示403错误，修改这个可以通过root去访问

worker_processes 2;worker_cpu_affinity 01 10

nginx默认是没有开启利用多核cpu的配置的。需要通过增加worker_cpu_affinity配置参数来充分利用多核cpu，cpu是任务处理，当计算最费时的资源的时候，cpu核使用上的越多，性能就越好。解释：01表示启用第一个CPU内核，10表示启用第二个CPU内核worker_cpu_affinity 01 10;表示开启两个进程，第一个进程对应着第一个CPU内核，第二个进程对应着第二个CPU内核。

error_log /var/log/nginx/error.log warn;

错误日志级别

worker_rlimit_nofile 20480;

更改worker进程的最大打开文件数限制, 如果没设置的话，这个值为操作系统的限制, 所以把这个值设高，这样nginx就不会有“too many open files”问题了。设置了这个后，修改worker_connections值时，是不能超过worker_rlimit_nofile的这个值（其实核心原因就是程序打开的文件/socket链接数量超过系统设定值）

use epoll;

使用epoll的I/O模型，这个不用说了吧。{select/pool/kqueue/epool ; select、poll是标准工作模式、kquque、epoll是搞笑工作模式，epoll是用在linux系统。kqueue是用在bsd系统（unix的衍生系统）

worker_connections 20480;

nginx默认的并发连接数是1024，如果网站访问量过大，就需要调整这个值，值越大能够支撑的并发数也就越大。但是最终的天花板是CPU; 理论上每台nginx服务器的最大连接数为worker_processes*worker_connections

accept_mutex off;

当一个新连接到达时，如果激活了accept_mutex，那么多个Worker将以串行方式来处理，其中有一个Worker会被唤醒，其他的Worker继续保持休眠状态；如果没有激活accept_mutex，那么所有的Worker都会被唤醒，不过只有一个Worker能获取新连接，其它的Worker会重新进入休眠状态，这就是「惊群问题」。假设你养了一百只小鸡，现在你有一粒粮食，那么有两种喂食方法：你把这粒粮食直接扔到小鸡中间，一百只小鸡一起上来抢，最终只有一只小鸡能得手，其它九十九只小鸡只能铩羽而归。这就相当于关闭了accept_mutex。你主动抓一只小鸡过来，把这粒粮食塞到它嘴里，其它九十九只小鸡对此浑然不知，该睡觉睡觉。这就相当于激活了accept_mutex。可以看到此场景下，激活accept_mutex相对更好一些，让我们修改一下问题的场景，我不再只有一粒粮食，而是一盆粮食，怎么办？此时如果仍然采用主动抓小鸡过来塞粮食的做法就太低效了，一盆粮食不知何年何月才能喂完，大家可以设想一下几十只小鸡排队等着喂食时那种翘首以盼的情景。此时更好的方法是把这盆粮食直接撒到小鸡中间，让它们自己去抢，虽然这可能会造成一定程度的混乱，但是整体的效率无疑大大增强了。

include /etc/nginx/mime.types;

这里我们使用它来加载文件扩展名与文件类型映射表。nginx根据映射关系，设置http请求响应头的Content-Type值。当在映射表找不到时，使用nginx.conf中default-type指定的默认值。

default_type application/octet-stream;

指定默认类型为二进制流，也就是当文件类型未 定义时使用这种方式

sendfile on;

开启高效传输模式

keepalive_timeout 60;

http连接的超时时间

include extra/*.conf;

通过不同配置文件进行管理