根据参数优化nginx的服务性能

一、优化nginx服务的worker进程数

在高并发、高访问量的Web服务场景，需要事先启动好更多的nginx进程，以保证快速响应并处理大量并发用户的请求。

1）、优化nginx进程对应的配置

优化nginx进程对应nginx服务的配置参数如下

cat nginx.conf
worker_processes  1;　　　　#指定了nginx要开启的进程数，结尾的数字就是进程的个数;

上述参数调整的是nginx服务的worker进程数，nginx有master进程和worker进程之分，master进程为管理进程，真正使用的是worker进程。

2）、优化nginx进程个数的策略

搭建服务器时,worker进程数最开始的设置可以等于CPU的核数,且worker进程数要多一些,这样起始提供服务时就不会出现因为访问量快速增加而临时启动新进程提供服务的问题,缩短了系统的瞬时开销和提供服务的时间,提升了服务用户的速度。高流量高并发场合也可以考虑将进程数提高至CPU核数*2,具体情况要根据实际的业务来选择,因为这个参数除了要和CPU核数匹配外,也和硬盘存储的数据及系统的负载有关,设置为CPU的核数是一个好的起始配置,这也是官方的建议。

 3）、查看Web服务器CPU硬件资产信息

查看CPU总颗数：
[root@nginx conf]# grep 'physical id' /proc/cpuinfo|sort|uniq|wc -l
1

查看CPU总核数：
[root@nginx conf]# grep processor /proc/cpuinfo |wc -l
4

4）、 修改nginx配置

假设服务器的CPU颗数为1颗，核数为1核，则初始法人配置可以通过查看默认的nginx.conf里的worker_processes数来了解，命令如下：

[root@nginx conf]# grep worker_processes nginx.conf
worker_processes  1;

这里修改参数值为CPU的总核数4，然后从新加载nginx服务。

root@nginx conf]# vim nginx.conf
[root@nginx conf]# grep worker_processes nginx.conf
worker_processes  4;

重新加载nginx服务并检查修改后的worker进程数量如下：

[root@nginx conf]# systemctl reload nginx
[root@nginx conf]# ps -ef|grep nginx|grep -v grep
root        748      1  0 8月31 ?       00:00:00 nginx: master process /application/nginx/sbin/nginx
www        1451    748  0 00:05 ?        00:00:00 nginx: worker process
www        1452    748  0 00:05 ?        00:00:00 nginx: worker process
www        1453    748  0 00:05 ?        00:00:00 nginx: worker process
www        1454    748  0 00:05 ?        00:00:00 nginx: worker process

从"worker_processes  4"可知，worker的进程数为4个。nginx的master主进程不包含在这个参数内，nginx master的主进程为管理进程，负责调度和管理worker进程。
有关worker_processes参数的官方说明如下：
syntax:    worker_processes number;    #此行为参数语法，number为数量;
default：   worker_processes  1；          #此行意思是不配置改参数，软件默认情况数量为1；
context:    main                                  #此行为worker_processes参数可以放置的位置;
worker_processes 为定义worker进程数的数量，建议设置为CPU的核数或CPU核数*2，具体情况要根据实际的业务来选择,因为这个参数除了要和CPU核数匹配外,也和硬盘存储的数据及系统的负载有关,设置为CPU的核数是一个好的起始配置。
From:http://nginx.org/en/docs/ngx_core_module.html

二、优化绑定不同的nginx进程到不同的CPU上

默认情况下，nginx的多个进程有可能跑在某一个CPU或CPU的某一核上，导致nginx进程使用硬件的资源不均本次的优化时尽可能的分配不同的nginx进程给不同的CPU处理，达到充分有效利用硬件的多CPU多核资源的目的。

在优化不同的nginx进程对应不同的CPU配置时，四核CPU服务器的参数配置参考如下：

[root@nginx conf]# grep worker nginx.conf
worker_processes  4;
worker_cpu_affinity 0001 0010 0100 1000;

worker_cpu_affinity就是配置nginx进程与CPU亲和力的参数，即把不同的进程分给不同的CPU处理。这里0001 0010 0100 1000是掩码，分别代表第1、2、3、4核CPU，由于worker_processes进程数为4，因此，上述配置会把每一个进程分配一核CPU处理，默认情况下进程不会绑定任何CPU，参数位置为main段。

worker_cpu_affinity参数的官方说明如下：

Syntax: 	worker_cpu_affinity cpumask ...;    #此行为CPU亲和力参数语法，cpumask为CPU掩码；
worker_cpu_affinity auto [cpumask];
Default: 	—　　　　　　　　　　　　　　　　　　　　 #默认不设置
Context: 	main　　　　　　　　　　　　　　　　　　 #此行为worker_cpu_affinity参数可以放置的位置；

worker_cpu_affinity的作用是绑定不同的worker进程数到一组CPU上，通过设置bitmask控制进程允许使用的CPU，默认worker进程不会绑定到任何CPU。

下面是绑定的示例配置：

 Binds worker processes to the sets of CPUs. Each CPU set is represented by a bitmask of allowed CPUs. There should be a separate set defined for each of the worker processes. By default, worker processes are not bound to any specific CPUs.

For example,

    worker_processes    4;
    worker_cpu_affinity 0001 0010 0100 1000;

binds each worker process to a separate CPU, while

    worker_processes    2;
    worker_cpu_affinity 0101 1010;

binds the first worker process to CPU0/CPU2, and the second worker process to CPU1/CPU3. The second example is suitable for hyper-threading.

The special value auto (1.9.10) allows binding worker processes automatically to available CPUs:

    worker_processes auto;
    worker_cpu_affinity auto;

The optional mask parameter can be used to limit the CPUs available for automatic binding:

    worker_cpu_affinity auto 01010101;

    The directive is only available on FreeBSD and Linux. 

翻译如下：

将工作进程绑定到CPU组。每个CPU集由允许的CPU的位掩码表示。应该为每个工作进程定义一个单独的集合。默认情况下，工作进程不绑定到任何特定的CPU。

例如，

worker_processes 4;
worker_cpu_affinity 0001 0010 0100 1000;
将每个工作进程绑定到一个单独的CPU，同时

worker_processes 2;
worker_cpu_affinity 0101 1010;
将第一个工作进程绑定到CPU0 / CPU2，将第二个工作进程绑定到CPU1 / CPU3。第二个例子适用于超线程。

特殊值auto（1.9.10）允许将工作进程自动绑定到可用的CPU：

worker_processes auto;
worker_cpu_affinity auto;
可选的mask参数可用于限制可用于自动绑定的CPU：

worker_cpu_affinity auto 01010101;
该指令仅适用于FreeBSD和Linux。 From:http://nginx.org/en/docs/ngx_core_module.html

三、nginx时间处理模型优化

Nginx的连接处理机制在不同的操作系统会采用不同的IO模型,在 Linux下, Nginx使用epol的vo多路复用模型,在Freebsd中使用kqueue的I/O多路复用模型,在Solaris中使用/dev/pol方式的I/O多路复用模型,在Windows中使用的是icop,等等。要根据系统类型选择不同的事件处理模型,可供使用的选择有“use[ kqueue|rtsig|epoll|/dev/poll | select | poll };"。本位使用的是centos7操作系统，因此将nginx的事件处理模型调整为epoll模型。

具体的配置参数如下：

vim nginx.conf

...
events {
    use epoll;        #添加这一行；
    worker_connections  1024;
}
...

说明：
use是一个事件模块指令,用来指定 Nginx的工作模式。Nginx支持的工作模式有 select、po11、 kqueue、epo11、 rtsig和/dev/po11。其中select和po11都是标准的工作模式, kqueue和epo11是高效的工作模式,不同的是epo11用在 Linux平台上,而 kqueue用在BSD系统中。对于
Linux系统 Linux2.6+的内核,推荐选择epo11工作模式,这是高性能高并发的设置。

根据nginx的官方文档建议，也可以不指定之间处理模型，nginx会自动选择最佳的事件处理模型服务。

events区块及use时间处理参数的官方说明如下：

syntax:    events {...}        #语法配置；
default:    _                      #缺省没有设置；
context:    main                #events标签的放置位置，放在main段；

events区块是一个用来设置链接进程的区块，例如:设置nginx的网络I/O模型，以及链接数等。
use事件的处理参数说明如下：
syntax:    use method;        #网络模型配置，method选择模型之一；
default：    —                      #缺省没有设置；
context：    events               #网络模型配置放置于events区块内；

对于使用链接进程的方法，通常不需要进行任何设置，你先会自动选择最有效的方法；

四、调整nginx单个进程允许的客户端最大链接数

调整nginx翻个进程允许的客户端最大链接数，这个控制连接数的参数为worker_connections。

worker_connections的值要根据本具体服务器性能和程序的内存使用量来指定（一个进程启动使用的内存根据程序确定），如下：

[root@nginx conf]# cat nginx.conf
...
events {
	use epoll;
    worker_connections  20480;
}
...

说明：
worker_connections也是个事件模块指令,用于定义 Nginx每个进程的最大连接数,默认是1024。最大客户端连接数由worker_ processes和worker_connections决定,即Max_client=worker_processes*worker_connections。进程的最大连接数受Linux系统进程的最大打开文件数限制,在执行操作系统命令"u1imit -HSn 65535"
或配置相应文件后, worker_connections的设置才能生效。

下面是worker_connections的官方说明：

参数语法：worker_connections
默认配置：worker_connections number
放置位置：events

worker_connections用来设置一个worker process支持的最大并发链接数，这个链接数包括了所有链接，例如：代理服务器的链接，客户端的链接等，实际的并发连接数除了接受worker_connections参数控制以外，还和最大打开文件数worker_rlimit_nofile有关，nginx总并发链接=worker数量*worker_connections.

From:http://nginx.org/en/docs/ngx_core_module.html

五、配置nginx worker进程最大打开文件数

调整nginx worker进程的最大打开文件数，这个控制链接数的参数行为worker_rlimit_nofile。改参数的配置如下：

[root@nginx conf]# cat nginx.conf

worker_processes  4;
worker_cpu_affinity 0001 0010 0100 1000;
worker_rlimit_nofile 65535;       #添加这一行；
events {
	use epoll;
    worker_connections  20480;
}
...

======================================================================================================

worker_rlimit_nofile 65535;

最大打开文件数，可设置为系统优化后的ulimit -HSh的结果。

下面是worker_rlimit_nofile的官方说明：
参数语法：worker_rlimit_nofile number
默认配置：无
放置位置：主标签段
说明：此参数的作用是改变worker processes能打开的最大文件数；

六、优化服务器域名的散列表大小

先要将确切名字和通配符名字存储在散列表中。散列表和监听端口关联,每个端口都最多关联到三张表:确切名字的散列表、以星号起始的通配符名字的散列表和以星号结束的通配符名字的散列表。散列表的尺寸在配置阶段进行了优化,可以以最小的CPU缓存命中失败来找到名字。nginx首先会搜索确切名字的散列表,如果没有找到,则搜索以星号起始的通配符名字的散列表,如果还是没有找到,继续搜索以星号结束的通配符名字的散列表。因为名字是按照域名的字节来搜索的,所以搜索通配符名字的散列表比搜索确切名字的散列表慢。注意 nginx.org存储在通配符名字的散列表中,而不在确切名字的散列表中。由于正则表达式是一个一个串行测试的,因此该方式也是最慢的,而且不可扩展。鉴于以上原因,请尽可能使用确切的名字。举个例子,如果使用 nginx.org和www.nginx.org来访问服务器是最频繁的,那么将它们明确地定义出来就更为有效,命令如下:

server {
   listen       80;
   server_name  nginx.org www.nginx.org *.nginx.org;
   ...
}

下面这种方法相比更简单，但是效率也更低：

server {
   listen       80;
   server_name  *.nginx.org;
   ...
}

如果定义了大量的名字,或者定义了非常长的名字,那就需要在HTTP配置块中调整 server_names_hash_max_size和 server_names_hash_bucket_size的值。 server_names_hash_bucket_size的默认值可能是32或64,也可能是其他值,这取决于CPU的缓存行的长度。如果这个值是32,那么定“too.long.server.name.nginx.org"作为虚拟主机名就会失败,此时会显示下面的错误信息:

could not build the server_names_hash,
you should increase server_names_hash_bucket_size: 32

出现了这种情况,那就需要将设置值扩大一倍,命令如下:

http {
server_names_hash_bucket_size 64;
...

如果定义了大量名字,会得到如下另外一个错误信息:

could not build the server_names_hash,
you should increase either server_names__hash_max_size: 512
or server_names_hash_bucket size: 32

那么应该先尝试设置 server_names_hash_max_size的值,此值差不多等于名字列表的名字总量。如果还不能解决问题,或者服务器启动非常缓慢,再尝试增加 server_names_hash _bucket_size的值,具体信息如下:

server_names_hash_max_size 512;　　　　#默认是512k,一般要查看系统给出确切的值。这里一般是cpu L1的4-5倍

server_names_hash_max_size的官方说明如下:

syntax:     server_names_hash_max_size size;        #参数语法
default:     server_names_hash_max_size 512;        #参数默认大小
context:    http                                    #仅能放置在http标签段

参数作用:设置存放域名( server names)的最大散列表大小。细节见http://nginx.org/en/docs/ngx_core_module.html
第二个参数如下:

server names hash bucket size 128;
#不能带单位!配置主机时必须设置该值,否则无法运行Nginx,或者无法通过测试。该设置与 server_names_hash_max_size共同控制保存服务器名的HASH表, hash bucket size总是等于hash表的大小,并且是一路处理器缓存大小的倍数。若 hash bucket size等于一路处理器缓存的大小,那么在查找键时,最坏的情况下在内存中查找的次数为2。第一次是确定存储单元的地址,第二次是在存储单元中查找键值。若报出 hash max size或 hash bucket size的提示,则需要增加 server_names_hash_max_size的值

server_names_hash_bucket_size的官方说明如下:

syntax:     server_ names _hash_bucket_size size;        #参数语法
default:     server_names_hash_bucket_size 32|64|128;    #参数默认大小
context:    http                                         #仅能放置在http标签段

参数作用:设置存放域名( server names)的最大散列表的存储桶( bucket)的大小
默认值依赖CPU的缓存行。细节见http://nginx.org/en/docs/ngx_core_module.html。

参考配置：

cat nginx.conf

......
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;
        client_max_body_size 50m;
		......
		......
	}
.......

七、开启高效文件传输模式

1）、设置参数：sendfile on;

sendfile参数用于开启文件的高效传输模式。同时将tcp_nopush和tcp_nodelay两个指定设为on，可防止网络及I/O阻塞，提升nginx工作效率。

sendfile参数的官方说明如下：

syntax:    sendfile on | off;    　　　　　　　　　　　　　　　　#参数语法
default:    sendfile off;    　　　　　　　　　　　　　　　　　　 #参数默认大小
context:    http, server, location, if in location　　　　　　#可以放置的标签段

参数作用:激活或禁用sendfile功能。sendfile是作用于两个文件描述符之间的数据拷贝函数,这个拷贝操作是在内核之中的,被称为"零拷贝", sendfile比read和writ函数要高效很多,因为,read和 wrtie函数要把数据拷贝到应用层再进行操作。相关控制参数还有 sendfile_max_chunk,可以自行查询。细节见http://nginx.org/en/docs/http/ngx_http_core_module.html#sendfile

2）、设置参数：tcp_nopush on；

tcp_nopush参数的官方说明如下：

syntax:    tcp_nopush on | off;        #参数语法
default:   tcp_nopush off;                #参数默认大小
context:   http, server, location        #可以放置的标签段

参数作用:激活或禁用 Linux上的 TCP_CORK socket选项,此选项仅仅当开启sendfile时才生效,激活这个tcp_nopush参数可以允许把http response header和文件的开始部分放在一个文件里发布,其积极的作用是减少网络报文段的数量。细节见http://nginx.org/en/docs/http/ngx_http_core_module.html

参考配置：

http
    {
		......
        sendfile   on;
        tcp_nopush on;
		......
	}

八、优化nginx连接参数，调整连接超时时间

nginx连接超时的参数设置

1）、设置参数：keepalive_timeout 60；

用于设置客户端连接保持会话的超时时间为60秒。超过这个时间，服务器会关闭该连接，此数值为参考值。

keepalive_timeout参数的官方说明如下：

Syntax:		keepalive_timeout timeout [header_timeout];		#参数语法;
Default:	keepalive_timeout 75s;							#参数默认大小;
Context:	http, server, location							#可以放置的标签段;

参数作用:keep-alive可以使客户端到服务器端已经建立的连接一直工作不退出,当服务器有持续请求时,keep-alive会使用已经建立的连接提供服务,从而避免服务器重新建立新连接处理请求。

此参数设置一个keep-alive(客户端连接在服务器端保持多久后退出,其单位是秒,和HTTP响应header域的"Keep-Alive:timeout=time"参数有关,这些header信息也会被客户端浏览器识别并处理,不过有些客户端并不能按照服务器端的设置来处理,例如:MSE大约60秒后会关闭 keep-alive连接。细节见http://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_timeout

 2）、设置参数tcp_nodelay on;

用于激活tcp_nodelay功能，提高I/O性能。

tcp_nodelay参数的官方说明如下：

Syntax:		tcp_nodelay on | off;		#参数语法;
Default:	tcp_nodelay on;				#参数默认大小;
Context:	http, server, location		#可以放置的标签段;

参数作用:默认情况下当数据发送时,内核并不会马上发送,可能会等待更多的字节组成一个数据包,这样可以提高I/O性能。但是,在每次只发送很少字节的业务场景
中,使用 tcp_nodelay功能,等待时间会比较长。参数生效条件:激活或禁用 TCP_NODELAY选项,当一个连接进入keep-alive状态时生效。细节见http://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_timeout

 3）、设置参数client_header_timeout 15;

用于设置读取客户端请求头数据的超时时间。此处的数值为15，其单位是秒，为参考值。

client_header_timeout参数的官方说明如下：

Syntax:		client_header_timeout time;		#默认语法
Default:	client_header_timeout 60s;		#参数默认设置
Context:	http, server					#可以放置的标签段

参数作用：设置读取客户端请求头数据的超时时间，如果超过这个时间，客户端还没有发送完整的header数据，服务器端将返回“Request time out（408）”错误，可以指定一个超时时间，放置客户端利用http协议进行攻击。细节见：http://nginx.org/en/docs/http/ngx_http_core_module.html#client_header_timeout

 4）、设置参数：client_body_timeout 15;

用于设置读取客户端请求主体的超时时间，默认值是60.

client_body_timeout参数的官方说明如下：

Syntax:		client_body_timeout time;
Default:	client_body_timeout 60s;
Context:	http, server, location

参数作用：设置读取客户端请求主体的超时时间。这个超时仅仅为两次成功的读取操作之间的一个超时，非请求整个主体数据的超时时间，如果在这个超时时间内，客户端没有发送任何数据，nginx将返回“Request time out（408）”错误，默认值是60。

 5）、设置参数：send_timeout 25;

用于指定响应客户端的超时时间。这个超时仅限于两个连接活动之间的时间，如果超过这个时间，客户端没有任何活动，nginx将会关闭连接，默认值是60秒，可以改为参考值25秒。

send_timeout的参数说明：

Syntax:        send_timeout time;
Default:    send_timeout 60s;
Context:    http, server, location

参数作用：设置服务器端传输HTTP想要信息到客户端的超时时间，这个超时仅仅为2次握手成功后的一个超时，非请求整个响应数据的超时时间，如果在这个超时时间内，客户端没有接收任何数据，nginx将会关闭连接。

参考设置：

http
    {
		......

        keepalive_timeout 60;

        tcp_nodelay on;

		......
	}

九、上传文件大小的限制（动态应用）

调整上传文件的大小（http Request body size）限制。

首先在nginx的主配置文件里加入如下参数：

client_max_body_size  8m;

具体大小根据实际情况做调整。

client_max_body_size参数说明：

Syntax:		client_max_body_size size;
Default:	client_max_body_size 1m;
Context:	http, server, location

参数作用：设置最大的允许的客户端请求主体大小，在请求头域有“Content-Length”，如果超过了此配置值，客户端会收到413错误，意思是请求的条目过大，有可能浏览器不能正确显示。设置为0表示禁止检查客户端请求主体大小。此参数对提高服务器的安全性有一定的作用。详见：http://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size

十、FastCGI相关参数调优（配合PHP引擎动态服务）

FastCGI参数是配合nginx向后请求PHP动态引擎服务的相关参数。nginx FastCGI工作的逻辑图如下：

nginx FastCGI常见参数列表说明：

fastcgi_connect_timeout:
表示 nginx服务器和后端FastcGI服务器连接的超时时间,默认值为60秒,这个参数值通常不要超过75秒,因为建立的连接越多,消耗的资源就越多;

fastcgi_send_timeout:
设置 Nginx允许 FastcGI服务器端返回数据的超时时间,即在规定时间之内后端服务器必须传完所有的数据,否则, nginx将断开这个连接。其默认
值为60秒;

fastcgi_read_timeout:
设置 nginx从 FastCGI服务器端读取响应信息的超时时间,表示连接建立成功后, Nginx等待后端服务器的响应时间,是 Nginx已经进入后端的排队之中等候
处理的时间;

fastcgi_buffer_size:
这是 Nginx FastCG的缓冲区大小参数,设定用来读取从 FastcGi服务器端收到的第一部分响应信息的缓冲区大小,这里的第一部分通常会包含一个小的响应
头部。默认情况下,这个参数的大小是由 fastcgi_buffers指定的一个缓冲区的大小;

fastcgi_buffers:
设定用来读取从 FastcgI服务器端收到的响应信息的缓冲区大小和缓冲区数量,默认值为 fastcgi_buffer8 4k|8k;
指定本地需要用多少和多大的缓冲区来缓冲 FastcGI的应答请求。如果一个PHP脚本所产生的页面大小为256KB,那么会为其分配4个64KB的缓冲区来缓存;
如果页面大小大于256KB,那么大于256KB的部分会缓存到fastcgi_temp指定的路径中,但是这并不是好方法,因为内存中的数据处理速度要快于硬盘。一般
这个值应该为站点中PHP脚本所产生的页面大小的中间值,如果站点大部分脚本所产生的页面大小为256KB,那么可以把这个值设置为"16 16k"、"4 64k"等;

proxy_busy_buffers_size:
用于设置系统很忙时可以使用的 proxy_buffers大小,官方推荐的大小为proxy buffers*2;

fastcgi_busy_buffers_size:
用于设置系统很忙时可以使用的 fastcgi buffers大小,官方推荐的大小为fastcgi_buffers*2;默认值为 fastcgi_busy_buffers_size 8k|16k;

fastcgi_temp_file_ write_size:
FastCG临时文件的大小,可设置为128~256KB

fastcgi_cache oldboy_nginx:
表示开启 FastCGI缓存并为其指定一个名称。开启缓存非常有用,可以有效降低CPU的负载,并且防止502错误的发生,但是开启缓存也可能引起其他问题,要根据具
体情况来选择;

fastcgi_cache_path:
示例: fastcgi_cache_path /data/ngx_fcgi_cache levels=2:2 keys_zone=ngx_fcgi_cache:512m inactive=1d max_size=40g;
fastcgi_cache缓存目录,可以设置目录前列层级,比如2:2会生成256*256个子目录, keys_zone是这个缓存空间的名字, cache是用多少内存(这样热门的内容, nginx会直接放入内存,
提高访问速度), inactive表示默认失效时间, max_size表示最多用多少硬盘空间,需要注意的是 fastcgi_cache缓存是先写在 fastcgi_temp_path再移到 fastcgi_cache_path中去的,所以这两个目录最好在同一个分区,从0.89之后可以在不同的分区,不过还是建议放在同一分区;

fastcgi_cache_valid:
示例: fastcgi_cache_valid 200 302 1h;
用来指定应答代码的缓存时间,实例中的值表示将200和302应答缓存一个小时;
示例: fastcgi_cache_valid 301 1d;
将301应答缓存1天;
示例: fastcgi_cache_valid_any 1m;
将其他应答缓存设置为1分钟;

fastcgi_cache_min_uses:
示例: fastcgi_cache_min_uses 1;
设置请求几次之后响应将被缓存,1表示一次即被缓存;

fastcgi_cache_use_stale:
示例:fastcgi_cache_use_stal eerror timeout invalid_header http_500;
定义在哪些情况下使用过期缓存;

fastcgi_cache_key：
示例：fastcgi_cache_key $request_method://$host$request_uri;fastcgi_cache_key http:://$host$request_uri;
定义 fastcgi_cache的key,示例中以请求的URI作为缓存的key, Nginx会取这个key的md5作为缓存文件,如果设置了缓存散列目录, Nginx会从后往前取相应的
位数做为目录。
注意一定要加上 $request_method作为 cache key,否则如果先请求的为head类型,后面的GET请求返回为空;

 FastCGI常见的nginx配置示例如下：

worker_processes  4;
worker_cpu_affinity 0001 0010 0100 1000;
worker_rlimit_nofile 65535;
user www;

events {
    use epoll;
    worker_connections  20480;
}

http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    server_tokens off;
    keepalive_timeout  65;

    server_names_hash_bucket_size 128;
    client_header_buffer_size 32k;
    large_client_header_buffers 4 32k;
    client_max_body_size 50m;

    tcp_nodelay on;

    client_header_timeout 15;
    client_body_timeout 15;
    send_timeout 15;

    log_format  main     '$remote_addr - $remote_user [$time_local] "$request" '
                         '$status $body_bytes_sent "$http_referer" '
                         '"$http_user_agent" "$http_x_forwarded_for"';

    fastcgi_connect_timeout 300;
    fastcgi_send_timeout 300;
    fastcgi_read_timeout 300;
    fastcgi_buffer_size 64k;
    fastcgi_buffers 4 64k;
    fastcgi_busy_buffers_size 128k;
    fastcgi_temp_file_write_size 256k;
    fastcgi_cache_path /data/ngx_fcgi_cache levels=2:2 keys_zone=ngx_fcgi_cache:512m inactive=1d max_size=40g;

    server {
        listen       80;
        server_name  www.dmtest.com;
        location / {
            root   html;
            index  index.php index.html index.htm;
        }

        location ~ .*\.(php|php5)?$
        {
        fastcgi_pass 127.0.0.1:9000;
        fastcgi_index index.php;
        include fastcgi.conf;
        fastcgi_cache ngx_fcgi_cache;
        fastcgi_cache_valid 200 302 1h;
        fastcgi_cache_valid 301 1d;
        fastcgi_cache_valid any 1m;
        fastcgi_cache_min_uses 1;
        fastcgi_cache_use_stale error timeout invalid_header http_500;
        fastcgi_cache_key http://$host$request_uri;
        }
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }
        access_log  logs/dmtest.log main;
    }
}

十一、配置nginx gzip压缩实现性能优化

1）nginx gzip压缩功能介绍

Nginxgzip压缩模块提供了压缩文件内容的功能,用户请求的内容在发送到用户客户端之前,nginx服务器会根据一些具体的策略实施压缩,以节约网站出口带 宽,同时加快数据传输效率,来提升用户访问体验。

2)、Nginx gzip压缩的优点

提升网站用户体验:发送给用户的内容小了,用户访问单位大小的页面就加快了,用户体验提升了,网站口碑就好了。
节约网站带宽成本:数据是压缩传输的,因此节省了网站的带宽流量成本,不过压缩时会稍微消耗一些CPU资源,这个一般可以忽略。

3)、需要和不需要压缩的对象

纯文本内容压缩比很高,因此,纯文本的内容最好进行压缩,例如:hml、jscss、xml、shtml等格式的文件。
被压缩的纯文本文件必须要大于1KB,由于压缩算法的特殊原因,极小的文件压缩后可能反而变大。
图片、视频(流媒体)等文件尽量不要压缩,因为这些文件大多都是经过压缩的,如果再压缩很可能不会减小或减小很少,或者有可能增大,同时压缩时还会消耗大量的CPU、内存资源

4)、参数介绍及配置说明

此压缩功能与早期 Apache服务的 mod_deflate压缩功能很相似, nginx的gzip压缩功能依赖于ngx_http_gzip_module模块,默认已安装。
对应的压缩参数说明如下:

gzip on;
开启gzip压缩功能。

gzip_min_length lk;
设置允许压缩的页面最小字节数,页面字节数从 header头的 Content-Length中获取。默认值是0,表示不管页面多大都进行压缩。建议设置成大于1K,
如果小于1K可能会越压越大。

gzip_buffers 4 16k;
压缩缓冲区大小。表示申请4个单位为16K的内存作为压缩结果流缓存,默认值是申请与原始数据大小相同的内存空间来存储gzip压缩结果。

gzip_http_version 1.1;
压缩版本(默认1.1,前端为 squid2.5时使用1.0),用于设置识别HTTP协议版本,默认是1.1,目前大部分浏览器已经支持G2IP解压,使用默认即可。

gzip_comp_level 2;
压缩比率。用来指定gzip压缩比,1压缩比最小,处理速度最快;9压缩比最大,传输速度快,但处理最慢,也比较消耗CPU资源。

gzip_types     text/plain application/javascript application/x-javascript text/javascript text/css application/xml applicat    ion/xml+rss;
用来指定压缩的类型,除了“ text/html” 之外，还允许对指定的MIME类型进行gzipping响应。特殊值“*”匹配任何MIME类型（0.8.29）。
text/html始终压缩具有“ ”类型的响应。

gzip_vary on;
vary header支持。该选项可以让前端的缓存服务器缓存经过gzip压缩的页面,例如用Squid缓存经过 Nginx压缩的数据。

gzip_proxied   expired no-cache no-store private auth;
根据请求和响应启用或禁用对代理请求的响应的gzipping。请求被代理的事实由“Via”请求头字段的存在确定。该指令接受多个参数：
	off
	禁用所有代理请求的压缩，忽略其他参数;
	expired
	如果响应头包含“Expires”字段，其值为禁用缓存，则启用压缩;
	no-cache
	如果响应头包含带有“ no-cache”参数的“Cache-Control”字段，则启用压缩;
	no-store
	如果响应头包含带有“ no-store”参数的“Cache-Control”字段，则启用压缩;
	private
	如果响应头包含带有“ private”参数的“Cache-Control”字段，则启用压缩;
	no_last_modified
	如果响应头不包含“Last-Modified”字段，则启用压缩;
	no_etag
	如果响应头不包含“ETag”字段，则启用压缩;
	auth
	如果请求标头包含“授权”字段，则启用压缩;
	any
	为所有代理请求启用压缩。

gzip_disable   "MSIE [1-6]\.";
对具有与任何指定正则表达式匹配的“User-Agent”标头字段的请求禁用gzipping响应。
特殊掩码“ msie6”（0.7.12）对应于正则表达式“ MSIE [4-6]\.”，但工作得更快。从版本0.8.11开始，“ MSIE 6.0; ... SV1”将从此掩码中排除。

From：http://nginx.org/en/docs/http/ngx_http_gzip_module.html

完整的配置如下：

放在http标签内：
      gzip on;
      gzip_min_length  1k;
      gzip_buffers     4 16k;
      gzip_http_version 1.1;
      gzip_comp_level 5;
      gzip_types     text/plain application/javascript application/x-javascript text/javascript text/css application/xml applicat       ion/xml+rss; 69         gzip_vary on; 70         gzip_proxied   expired no-cache no-store private auth;
      gzip_disable   "MSIE [1-6]\.";

十二、配置nginx expires 缓存实现性能优化

1）、nginx expires功能介绍

简单地说, Nginx expires的功能就是为用户访问的网站内容设定一个过期时间,当用户第一次访问这些内容时,会把这些内容存储在用户浏览器本地,这样用户第二次及以后继续访问该网站时,浏览器会检查加载已经缓存在用户浏览器本地的内容,就不会去服务器下载了,直到缓存的内容过期或被清除为止。

更深入地理解:expires的功能就是允许通过Nginx配置文件控制HTTP的"Expires"和" Cache-Contro"响应头部内容,告诉客户端浏览器是否缓存和缓存多久以内访问的内容。这个 expires模块控制 nginx服务器应答时的 expires头内容和 Cache-Control头的max-age指令。缓存的有效期可以设置为
相对于源文件的最后修改时刻或客户端的访问时刻。

这些HTTP头向客户端表明了内容的有效性和持久性。如果客户端本地有内容缓存,则内容就可以从缓存(除非已经过期)而不是从服务器中读取,然后客户端会检查缓存中的副本,看其是否过期或失效,以决定是否重新从服务器获得内容更新。

2)、 Nginx expires作用介绍
在网站的开发和运营中,视频、图片、CSS、JS等网站元素的更改机会较少,特别是图片,这时可以将图片设置在客户浏览器本地缓存365天或3650天,而将CSS、JS、html等代码缓存10~30天。这样用户第一次打开页面后,会在本地的浏览器按照过期日期缓存相应的内容,下次用户再打开类似的页面时,重复的元素就无需下载了,从而加快用户访问速度。用户的访问请求和数据减少了,也可节省大量的服务器端带宽。此功能同 Apache的 expires功能类似

3)、 Nginx expires功能优点

expires可以降低网站的带宽,节约成本。

加快用户访问网站的速度,提升用户访问体验。

服务器访问量降低了,服务器压力就减轻了,服务器成本也会降低,甚至可以节约人力成本。

对于几乎所有的Web服务来说,这是非常重要的功能之一, Apache服务也有此功能。

4）、nginx expires 配置详解

根据文件扩展名进行判断，添加expires功能示例

示例1：

     location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$
     {
         expires      30d;
     }   

该示例的意思是当用户访问网站URL结尾的文件扩展名为上述指定类型的图片时，设置缓存为30天。

示例2：

      location ~ .*\.(js|css)?$
      {
          expires      12h;
      }   

该示例的意思是当用户访问网站URL结尾的文件扩展名为js、css类型的元素时，设置缓存为12小时。

根据URL中的路径（目录）进行判断，添加expires功能示例

示例：

##Add expires header caaording to URL(path or dir).
location  ~ ^/(images|javascript|js|css|flash|media|static)/{
        expires 360d;
}

该示例的意思是当用户访问网站URL中包含上述路径（例：images、js、css，这些在服务器端是程序目录）时，把访问的内容设置缓存360天。

单个文件添加expires功能的示例

下面的命令会给robots.txt机器人设置过期时间（这里为7天），在这7天并不一定记录404错误日志。

location ~(robots.txt) {
        expires 7d;
        break;
}

最终配置如下：

放在server标签内：

      location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$
      {
          expires      30d;
      }

      location ~ .*\.(js|css)?$
      {
          expires      12h;
      }

      location ~ /.well-known {
          allow all;
      }

      location ~ /\.
      {
          deny all;
      }

5）、nginx expires配置效果检查

在Linux客户端可以通过如下curl命令查看图片URL的缓存header信息：

[root@test default]# curl -I 127.0.0.1/lnmp.gif
HTTP/1.1 200 OK
Server: nginx
Date: Sun, 02 Sep 2018 01:13:06 GMT
Content-Type: image/gif
Content-Length: 5683
Last-Modified: Thu, 16 Aug 2018 08:40:36 GMT
Connection: keep-alive
ETag: "5b753884-1633"
Expires: Tue, 02 Oct 2018 01:13:06 GMT    #缓存的过期时间
Cache-Control: max-age=2592000             #缓存的总时间，单位为秒
Accept-Ranges: bytes

Windows下需要通过火狐浏览器加yslow插件查看。

6）、nginx expires功能确定及解决方法

当网站被缓存的页面或数据更新了,此时用户端看到的可能还是旧的已经缓存的内容,这样就会影响用户体验,那么如何解决这个问题呢?解决办法如下。

第一,对于经常需要变动的图片等文件,可以缩短对象缓存时间,例如:谷歌和百度的首页的图片经常根据不同的日期换成一些节日的图,所以这里可以将这个图片设置为缓存期为1天。

第二,当网站改版或更新时,可以在服务器将缓存的对象改名(网站代码程序)。

对于网站的图片、附件,一般不会被用户直接修改,用户层面上的修改图片,实际上是重新传到服务器,虽然内容一样但是是一个新的图片名了。

网站改版升级会修改JS、CSS元素,若改版时对这些元素改了名,会使得前端的CDN及用户端需要重新缓存内容。