主要是Nginx.conf配置的优化：其中配置文件分为main、http、server
官方链接： nginx官方链接配置文件使用说明
一：main全局优化和规范：
优化work进程-运行用户-进程最大打开文件数-定义pid-定义日志路径
user www www; #运行用户，默认即是nginx，可不设置
worker_processes auto; #nginx进程,一般设置为和cpu核数一样
error_log /data/logs/error/error_nginx.log crit; #定义错误日志文件位置和错误级别
pid /var/run/nginx.pid; #定义pid文件存放位置
worker_rlimit_nofile 65535; #最大文件打开数（连接），可设置为系统优化后的ulimit -n的结果
查看cpu总核数
[root@node01 ~]# grep processor /proc/cpuinfo |wc -l
4
查看cpu总个数
[root@node01 ~]# grep 'physical id' /proc/cpuinfo|sort|uniq|wc -l
2
[root@node01 ~]# lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 1
Core(s) per socket: 2
Socket(s): 2
|
worker_processes 了解一下,免得以后看到不知道什么鬼，
测压结果：直接写4和把进程分别绑定到不同的CPU CPU的使用率区别不大 也可以将进程绑定到不同的CPU， worker_processes 4; cpu亲和力配置，让不同的进程使用不同的cpu worker_cpu_affinity 0001 0010 0100 1000; 八个线程CPU的配置： worker_processes 8; worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000； worker_cpu_affinity 0001 0010 0100 1000 0001 0010 0100 1000； |
二：events优化
events {
use epoll; #用来指定nginx的工作模式
worker_connections 51200; #单个后台worker process进程的最大并发链接数
multi_accept on; #打开同时接受多个新网络连接请求的功能
#accept_mutex on; #该指令1.113版本之前默认为on状态，表示会对多个Nginx进程接收连接进行序列化，防止多个进程对连接的争抢
}
events详细说明
|
use epoll用来指定nginx的工作模式，
nginx工作模式有select epoll poll kqueue rtsig和/dev/null select和poll都是标准的工作模式 kqueue和epoll是高效的工作模式 epoll用在Linux平台 kqueue用在BSD系统 ，异步网络I/O模型 对于Linux系统2.6+内核推荐epoll，高性能高并发的设置 官方文档：也可以不指定事件处理模型，nginx会自动选择最佳的事件处理模型服务 |
|
worker_connections 51200;
|
|
multi_accept on; #打开同时接受多个新网络连接请求的功能
只能在events模块设置， Nginx服务器的每个工作进程可以同时接受多个新的网络连接， 但是需要在配置文件中配置，此指令默认为关闭， 即默认为一个工作进程只能一次接受一个新的网络连接， 打开后几个同时接受多个，配置语法如下： |
|
指令格式：accept_mutex on | off; 该指令1.113版本之前默认为on、之后的版本默认为off状态，表示会对多个Nginx进程接收连接进行序列化，防止多个进程对连接的争抢。 「惊群问题」 举例说明：假如有100只小鸡 |
三：events优化
http {
include mime.types;
default_type application/octet-stream;
server_names_hash_bucket_size 128;
client_header_buffer_size 32k;
large_client_header_buffers 4 32k;
server_tokens off; #隐藏版本号nginx
sendfile on; #开启文件的高效传输模式，同时将 tcp_nopush on; tcp_nodelay on; 可以防止网络及磁盘I/O阻塞，
tcp_nopush on; #准许把 http response header 和文件的开始部分放在一个文件里发布，其积极的作用是减少网络报文的数量
tcp_nodelay on; #提高I/O性能
keepalive_timeout 60 ; #客户端 与服务端（nginx）服务端 建立连接超时时间
client_header_timeout 15; #服务端（nginx） 读取 客户端请求头数据 的超时时间
client_body_timeout 15; #服务端（nginx）读取 客户端请求主体数据 的超时时间
send_timeout 25; #服务端（nginx） 传送 http响应信息 到 客户端 的超时时间
client_max_body_size 16m; #上传文件大小限制！！！设置最大准许 客户端请求主体大小，一般情况下http的post方法在提交数据时才会携带请求主体
}
|
官方链接说明： server_names_hash_bucket_size 分别搜 三个指令即可搜到详细作用
Syntax : server_names_hash_bucket_size size;
Default: server_names_hash_bucket_size 32|64|128; Context: http Syntax : client_header_buffer_size size; Default: client_header_buffer_size 1k; Context: http, server 设置读取客户端请求标头的缓冲区大小。对于大多数请求，1K字节的缓冲区就足够了。但是，如果请求包含长cookie或来自WAP客户端，则可能不适合1K。如果请求行或请求头字段不适合此缓冲区，则会分配由large_client_header_buffers指令配置的较大缓冲区 Syntax : large_client_header_buffers number size; Default: large_client_header_buffers 4 8k; Context: http, server 设置用于读取大客户机请求标头的最大值number和size缓冲区。请求行不能超过一个缓冲区的大小，否则会将414（Request-URITooLarge）错误返回给客户端。请求头字段也不能超过一个缓冲区的大小，或者400（错误请求）错误返回给客户端。缓冲区仅按需分配。默认情况下，缓冲区大小等于8K字节。如果在请求处理结束后连接转换为保持活动状态，则释放这些缓冲区。 |
|
超时设置说明： |
|
Syntax : client_body_buffer_size size;
Default: client_body_buffer_size 8k|16k; Context: http, server, location 设置读取客户端请求主体的缓冲区大小。如果请求主体大于缓冲区，则整个主体或仅其部分被写入 临时文件。默认情况下，缓冲区大小等于两个内存页。这在x86，其他32位平台和x86-64上是8K。在其他64位平台上通常为16K。 官方说明 client_body_temp_path 本文中没有设置 Syntax : client_max_body_size size; Default: client_max_body_size 1m; Context: http, server, location 设置客户端请求正文的最大允许大小，在“Content-Length”请求标头字段中指定。如果请求中的大小超过配置的值，则会将413（请求实体太大）错误返回给客户端。请注意，浏览器无法正确显示此错误。设置 size为0将禁用检查客户端请求正文大小。 |
