Nginx中并发性能相关配置参数说明

• worker_processes：开启worker进程的数目，一般可设置为CPU核心的倍数。在不清楚的状况下，可设置成一倍于CPU核心数或auto(Nginx将自动发现CPU核心数)。
• worker_connections：单个worker可处理并发链接的上限，但实际并发链接数可否达到这个值还与系统其余资源限制有关。当前Nginx实例可处理的并发链接数为 worker_processes *  worker_connections。
• worker_rlimit_nofile：worker可打开文件数上限(每一个套接字打开一个文件描述符)，worker_rlimit_nofile相似于系统配置ulimit -n(不过ulimit -n设置的最大值不能超过65536，且只能在当前shell环境中生效，重启后无效)。
• limit_conn_zone：定义链接域，一般要与limit_conn配合使用。

  limit_conn_zone $binary_remote_addr zone=addr:10m;#shared memory size: 10m

• limit_conn：为指定域中的每一个key配置并发链接数，当实际链接请求数超出该值则拒绝。

  limit_conn_zone $binary_remote_addr zone=addr:10m;#shared memory size 10m
  
  server {
      ...
      limit_conn addr 1;#allow only one connection per an IP address at a time.
  }

  但要记住的是，

  In HTTP/2 and SPDY, each concurrent request is considered a separate connection.

• limit_conn_status：当链接请求被拒绝后返回的状态码，默认503。

• limit_req_zone：它是基于漏桶(Leaky Bucket)算法实现的，

  http {
      limit_req_zone $binary_remote_addr zone=one:10m rate=10r/m;
      ...
      server {
          ...
          location /search/ {
              limit_req zone=one burst=5 nodelay;
          }

• limit_req：来不及处理的请求被延迟执行，直到它们的数量超过burst(漏桶的最大容量，默认为0)，即溢出(Nginx将拒绝该请求)；在上例中，nodelay表示在记时一分钟内，即便请求未溢出，只要是超出了10个后也直接拒绝。

• limit_req_status：当请求被拒绝后返回的状态码，默认503。
• limit_rate：这是ngx_http_core_module提供的功能，用于限制Nginx的下载速率。若是是对代理限速，也可使用X-Accel-Limit-Rate响应头。

  location /download { 
         limit_rate_after 10m; 
         limit_rate 128k; 
   }  

• limit_rate_after：一般与limit_rate一块儿使用。在上例中，10m之前不限速，10m之后才限制下载速率。
• accept_mutex：默认为off，V1.11.3前默认为on， There is no need to enable accept_mutex on systems that support the EPOLLEXCLUSIVE flag (1.11.3) or when using reuseport. 当一个新链接到来时，全部可用的worker将从等待状态被唤醒，最终却只有一个worker能接受并处理链接，这就是所谓的惊群现象；若是这种现象每秒重复屡次，将致使服务器性能降低，由于全部被唤醒的worker都在占用CPU时间，而增长了非生产性CPU周期和未使用的上下文切换。但Linux系统底层已经解决了这个问题，Nginx 自1.11.3开始支持EPOLLEXCLUSIVE flag，所以accept_mutex默认变为off。

  events {
       accept_mutex on;#worker processes will accept new connections by turn.
  }

   

• accept_mutex_delay：当启用accept_mutex时，只有一个具备互斥锁的worker接受链接，其余worker则轮流等待accept_mutex_delay指定的时间。
• multi_accept：默认为off。值为on使得worker可以在得到新链接通知时接受全部链接并放到监听队列中，值为off使得worker将逐个接受新链接。
• thread_pool：采用asynchronous file I/O (AIO)，多线程读写不锁worker。Nginx 1.7.11以上的版本可以使用，加 --with-threads 配置参数编译。
  
  
  

  
  
  

  上图展现了Nginx的事件队列是在循环中顺序执行的，可能存在又长又重的操做(阻塞操做)致使事件处理循环卡住，其余事件必须等待这个操做执行完毕，所以而引入线程池；但在cache情景下，线程池并不会带来性能提高，反而应避免使用。

  Syntax:	thread_pool name threads=number [max_queue=number];
  Default: thread_pool default threads=32 max_queue=65536;
  Context: main
  This directive appeared in version 1.7.11.

  http {
      thread_pool one threads=128 max_queue=0;
      thread_pool two threads=32;
  
      server {
          location /one {
              aio threads=one;
          }
  
          location /two {
              aio threads=two;
          }
      }
  …
  }

   

• aio(asynchronous file I/O)：开启或关闭异步文件I/O功能，它也容许aio使用线程池。Nginx官方给aio使用线程池的测试案例得9倍性能提高，可参考 NGINX引入线程池 性能提高9倍。

  Syntax:	aio on | off | threads[=pool];
  Default:	aio off;
  Context:	http, server, location

   

• keepalive： 在每个worker进程的cache中建立一个到upstream的空闲keepalive链接池。若是keepalive池中的链接用完，Nginx依然能够向upstream发出更多的新链接，链接池只是起到缓存空闲keepalive链接的做用。It should be particularly noted that the keepalive directive does not limit the total number of connections to upstream servers that an nginx worker process can open. The connections parameter should be set to a number small enough to let upstream servers process new incoming connections as well.

  upstream fastcgi_backend {
      server 127.0.0.1:9000;
  
      keepalive 8;#链接池最大容量8。When this number is exceeded, the least recently used connections are closed.
  }
  
  server {
      ...
  
      location /fastcgi/ {
          fastcgi_pass fastcgi_backend;
          fastcgi_keep_conn on;
          ...
      }
  }

   

   

若是正常流量并不高，某些参数设置无需太高；不然，一旦遭遇DDOS攻击，将有可能致使服务器瘫痪。