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攻擊，將有可能致使服務器癱瘓。