Nginx性能调优

Nginx配置参数优化

Nginx做为高性能web服务器，即便不特地调整配置参数也能够处理大量的并发请求。
如下的配置参数是借鉴网上的一些调优参数，仅做为参考，不见得适于你的线上业务。

worker进程

• worker_processes

  该参数表示启动几个工做进程，建议和本机CPU核数保持一致，每一核CPU处理一个进程。

• worker_rlimit_nofile

  它表示Nginx最大可用的文件描述符个数，须要配合系统的最大描述符，建议设置为102400。
  还须要在系统里执行ulimit -n 102400才能够。
  也能够直接修改配置文件/etc/security/limits.conf修改
  增长：
  #* soft nofile 655350 (去掉前面的#)
  #* hard nofile 655350 (去掉前面的#)

• worker_connections

  该参数用来配置每一个Nginx worker进程最大处理的链接数，这个参数也决定了该Nginx服务器最多能处理多少客户端请求
  （worker_processes * worker_connections)，建议把该参数设置为10240，不建议太大。

http和tcp链接

• use epoll

  使用epoll模式的事件驱动模型，该模型为Linux系统下最优方式。

• multi_accept on

  使每一个worker进程能够同时处理多个客户端请求。

• sendfile on

  使用内核的FD文件传输功能，能够减小user mode和kernel mode的切换，从而提高服务器性能。

• tcp_nopush on

  当tcp_nopush设置为on时，会调用tcp_cork方法进行数据传输。
  使用该方法会产生这样的效果：当应用程序产生数据时，内核不会立马封装包，而是当数据量积累到必定量时才会封装，而后传输。

• tcp_nodelay on

  不缓存data-sends（关闭 Nagle 算法），这个可以提升高频发送小数据报文的实时性。
  (关于Nagle算法)
  【假如须要频繁的发送一些小包数据，好比说1个字节，以IPv4为例的话，则每一个包都要附带40字节的头，
  也就是说，总计41个字节的数据里，其中只有1个字节是咱们须要的数据。
  为了解决这个问题，出现了Nagle算法。
  它规定：若是包的大小知足MSS，那么能够当即发送，不然数据会被放到缓冲区，等到已经发送的包被确认了以后才能继续发送。
  经过这样的规定，能够下降网络里小包的数量，从而提高网络性能。】

• keepalive_timeout

  定义长链接的超时时间，建议30s，过短或者太长都不必定合适，固然，最好是根据业务自身的状况来动态地调整该参数。

• keepalive_requests

  定义当客户端和服务端处于长链接的状况下，每一个客户端最多能够请求多少次，能够设置很大，好比50000.

• reset_timeout_connection on

  设置为on的话，当客户端再也不向服务端发送请求时，容许服务端关闭该链接。

• client_body_timeout

  客户端若是在该指定时间内没有加载完body数据，则断开链接，单位是秒，默认60，能够设置为10。

• send_timeout

  这个超时时间是发送响应的超时时间，即Nginx服务器向客户端发送了数据包，但客户端一直没有去接收这个数据包。
  若是某个链接超过send_timeout定义的超时时间，那么Nginx将会关闭这个链接。单位是秒，能够设置为3。

buffer和cache(如下配置都是针对单个请求)

• client_body_buffer_size

  当客户端以POST方法提交一些数据到服务端时，会先写入到client_body_buffer中，若是buffer写满会写到临时文件里，建议调整为128k。

• client_max_body_size

  浏览器在发送含有较大HTTP body的请求时，其头部会有一个Content-Length字段，client_max_body_size是用来限制Content-Length所示值的大小的。
  这个限制body的配置不用等Nginx接收完全部的HTTP包体，就能够告诉用户请求过大不被接受。会返回413状态码。
  例如，用户试图上传一个1GB的文件，Nginx在收完包头后，发现Content-Length超过client_max_body_size定义的值，
  就直接发送413(Request Entity Too Large)响应给客户端。
  将该数值设置为0，则禁用限制，建议设置为10m。

• client_header_buffer_size

  设置客户端header的buffer大小，建议4k。

• large_client_header_buffers

  对于比较大的header（超过client_header_buffer_size）将会使用该部分buffer，两个数值，第一个是个数，第二个是每一个buffer的大小。
  建议设置为4 8k

• open_file_cache

  该参数会对如下信息进行缓存：
  打开文件描述符的文件大小和修改时间信息;
  存在的目录信息;
  搜索文件的错误信息（文件不存在无权限读取等信息）。
  格式：open_file_cache max=size inactive=time;
  max设定缓存文件的数量，inactive设定通过多长时间文件没被请求后删除缓存。
  建议设置 open_file_cache max=102400 inactive=20s;

• open_file_cache_valid

  指多长时间检查一次缓存的有效信息。建议设置为30s。

• open_file_cache_min_uses

  open_file_cache指令中的inactive参数时间内文件的最少使用次数，
  如,将该参数设置为1，则表示，若是文件在inactive时间内一次都没被使用，它将被移除。
  建议设置为2。

压缩

对于纯文本的内容，Nginx是可使用gzip压缩的。使用压缩技术能够减小对带宽的消耗。
由ngx_http_gzip_module模块支持

配置以下：
gzip on; //开启gzip功能
gzip_min_length 1024; //设置请求资源超过该数值才进行压缩，单位字节
gzip_buffers 16 8k; //设置压缩使用的buffer大小，第一个数字为数量，第二个为每一个buffer的大小
gzip_comp_level 6; //设置压缩级别，范围1-9,9压缩级别最高，也最耗费CPU资源
gzip_types text/plain application/x-javascript text/css application/xml image/jpeg image/gif image/png; //指定哪些类型的文件须要压缩
gzip_disable "MSIE 6\."; //IE6浏览器不启用压缩

测试：
curl -I -H "Accept-Encoding: gzip, deflate" http://www.wangzb.com/1.css

日志

• 错误日志级别调高，好比crit级别，尽可能少记录可有可无的日志。
• 对于访问日志，若是不要求记录日志，能够关闭，
• 静态资源的访问日志关闭

静态文件过时

对于静态文件，须要设置一个过时时间，这样可让这些资源缓存到客户端浏览器，
在缓存未失效前，客户端再也不向服务期请求相同的资源，从而节省带宽和资源消耗。

配置示例以下：
location ~* ^.+\.(gif|jpg|png|css|js)$                                      
{
    expires 1d; //1d表示1天，也能够用24h表示一天。
}

做为代理服务器

Nginx绝大多数状况下都是做为代理或者负载均衡的角色。
由于前面章节已经介绍过如下参数的含义，在这里只提供对应的配置参数：
http
{
    proxy_cache_path /data/nginx_cache/ levels=1:2 keys_zone=my_zone:10m inactive=300s max_size=5g;
    ...;
    server
    {
	proxy_buffering on;
	proxy_buffer_size 4k;
	proxy_buffers 2 4k;
	proxy_busy_buffers_size 4k;
	proxy_temp_path /tmp/nginx_proxy_tmp 1 2;
	proxy_max_temp_file_size 20M;
	proxy_temp_file_write_size 8k;
	
	location /
	{
	    proxy_cache my_zone;
	    ...;
	}
    }
}

SSL优化

• 适当减小worker_processes数量，由于ssl功能须要使用CPU的计算。

• 使用长链接，由于每次创建ssl会话，都会耗费必定的资源（加密、解密）

• 开启ssl缓存，简化服务端和客户端的“握手”过程。

  ssl_session_cache   shared:SSL:10m; //缓存为10M
  ssl_session_timeout 10m; //会话超时时间为10分钟

 调整Linux内核参数

做为高性能WEB服务器，只调整Nginx自己的参数是不行的，由于Nginx服务依赖于高性能的操做系统。
如下为常见的几个Linux内核参数优化方法。

• 1 net.ipv4.tcp_max_tw_buckets

  对于tcp链接，服务端和客户端通讯完后状态变为timewait，假如某台服务器很是忙，链接数特别多的话，那么这个timewait数量就会愈来愈大。
  毕竟它也是会占用必定的资源，因此应该有一个最大值，当超过这个值，系统就会删除最先的链接，这样始终保持在一个数量级。
  这个数值就是由net.ipv4.tcp_max_tw_buckets这个参数来决定的。
  CentOS7系统，你可使用sysctl -a |grep tw_buckets来查看它的值，默认为32768，
  你能够适当把它调低，好比调整到8000，毕竟这个状态的链接太多也是会消耗资源的。
  但你不要把它调到几10、几百这样，由于这种状态的tcp链接也是有用的，
  若是一样的客户端再次和服务端通讯，就不用再次创建新的链接了，用这个旧的通道，省时省力。

• 2 net.ipv4.tcp_tw_recycle = 1

  该参数的做用是快速回收timewait状态的链接。上面虽然提到系统会自动删除掉timewait状态的链接，但若是把这样的链接从新利用起来岂不是更好。
  因此该参数设置为1就可让timewait状态的链接快速回收，它须要和下面的参数配合一块儿使用。

• 3 net.ipv4.tcp_tw_reuse = 1

  该参数设置为1，将timewait状态的链接从新用于新的TCP链接，要结合上面的参数一块儿使用。

• 4 net.ipv4.tcp_syncookies = 1

  tcp三次握手中，客户端向服务端发起syn请求，服务端收到后，也会向客户端发起syn请求同时连带ack确认，
  假如客户端发送请求后直接断开和服务端的链接，不接收服务端发起的这个请求，服务端会重试屡次，
  这个重试的过程会持续一段时间（一般高于30s），当这种状态的链接数量很是大时，服务器会消耗很大的资源，从而形成瘫痪，
  正常的链接进不来，这种恶意的半链接行为其实叫作syn flood攻击。
  设置为1，是开启SYN Cookies，开启后能够避免发生上述的syn flood攻击。
  开启该参数后，服务端接收客户端的ack后，再向客户端发送ack+syn以前会要求client在短期内回应一个序号，
  若是客户端不能提供序号或者提供的序号不对则认为该客户端不合法，因而不会发ack+syn给客户端，更涉及不到重试。

• 5 net.ipv4.tcp_max_syn_backlog

  该参数定义系统能接受的最大半链接状态的tcp链接数。客户端向服务端发送了syn包，服务端收到后，会记录一下，
  该参数决定最多能记录几个这样的链接。在CentOS7，默认是256，当有syn flood攻击时，这个数值过小则很容易致使服务器瘫痪，
  实际上此时服务器并无消耗太多资源（cpu、内存等），因此能够适当调大它，好比调整到30000。

• 6 net.ipv4.tcp_syn_retries

  该参数适用于客户端，它定义发起syn的最大重试次数，默认为6，建议改成2。

• 7 net.ipv4.tcp_synack_retries

  该参数适用于服务端，它定义发起syn+ack的最大重试次数，默认为5，建议改成2，能够适当预防syn flood攻击。

• 8 net.ipv4.ip_local_port_range

  该参数定义端口范围，系统默认保留端口为1024及如下，以上部分为自定义端口。这个参数适用于客户端，
  当客户端和服务端创建链接时，好比说访问服务端的80端口，客户端随机开启了一个端口和服务端发起链接，
  这个参数定义随机端口的范围。默认为32768    61000，建议调整为1025 61000。

• 9 net.ipv4.tcp_fin_timeout

  tcp链接的状态中，客户端上有一个是FIN-WAIT-2状态，它是状态变迁为timewait前一个状态。
  该参数定义不属于任何进程的该链接状态的超时时间，默认值为60，建议调整为6。

• 10 net.ipv4.tcp_keepalive_time

  tcp链接状态里，有一个是established状态，只有在这个状态下，客户端和服务端才能通讯。正常状况下，当通讯完毕，
  客户端或服务端会告诉对方要关闭链接，此时状态就会变为timewait，若是客户端没有告诉服务端，
  而且服务端也没有告诉客户端关闭的话（例如，客户端那边断网了），此时须要该参数来断定。
  好比客户端已经断网了，但服务端上本次链接的状态依然是established，服务端为了确认客户端是否断网，
  就须要每隔一段时间去发一个探测包去确认一下看看对方是否在线。这个时间就由该参数决定。它的默认值为7200秒，建议设置为30秒。

• 11 net.ipv4.tcp_keepalive_intvl

  该参数和上面的参数是一块儿的，服务端在规定时间内发起了探测，查看客户端是否在线，若是客户端并无确认，
  此时服务端还不能认定为对方不在线，而是要尝试屡次。该参数定义从新发送探测的时间，即第一次发现对方有问题后，过多久再次发起探测。
  默认值为75秒，能够改成3秒。

• 12 net.ipv4.tcp_keepalive_probes

  第10和第11个参数规定了什么时候发起探测和探测失败后再过多久再发起探测，但并无定义一共探测几回才算结束。
  该参数定义发起探测的包的数量。默认为9，建议设置2。

设置和范例

在Linux下调整内核参数，能够直接编辑配置文件/etc/sysctl.conf，而后执行sysctl -p命令生效

结合以上分析的各内核参数，范例以下
net.ipv4.tcp_fin_timeout = 6
net.ipv4.tcp_keepalive_time = 30
net.ipv4.tcp_max_tw_buckets = 8000
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 30000
net.ipv4.tcp_syn_retries = 2
net.ipv4.tcp_synack_retries = 2
net.ipv4.ip_local_port_range = 1025 61000
net.ipv4.tcp_keepalive_intvl = 3
net.ipv4.tcp_keepalive_probes = 2