A、正常執行的配置項

（1）Nginx worker程序執行的使用者及使用者組
語法： user username [groupname];
預設： user nobody nobody;
      user用於設定master程序啟動後，fork出的worker程序執行在哪個使用者和使用者組下。當按照“user username;”設定時，使用者組名與使用者名稱相同。若使用者在configure命令執行時使用了引數--user=username和--group=groupname，此時nginx.conf將使用引數中指定的使用者和使用者組。

（2）指定Nginx worker程序可以開啟的最大控制代碼描述符個數
語法： worker_rlimit_nofile limit;
設定一個worker程序可以開啟的最大檔案控制代碼數。

（3）限制訊號佇列
語法： worker_rlimit_sigpending limit;
設定每個使用者發往Nginx的訊號佇列的大小。也就是說，當某個使用者的訊號佇列滿了，這個使用者再發送的訊號量會被丟掉。

 B、優化效能的配置項
下面是優化效能的配置項的相關介紹。

（1）Nginx worker程序個數
語法： worker_processes number;
預設： worker_processes 1;
在master/worker執行方式下，定義worker程序的個數。worker程序的數量會直接影響效能。那麼，使用者配置多少個worker程序才好呢？這實際上與業務需求有關。
每個worker程序都是單執行緒的程序，它們會呼叫各個模組以實現多種多樣的功能。如果這些模組確認不會出現阻塞式的呼叫，那麼，有多少CPU核心就應該配置多少個程序；反之，如果有可能出現阻塞式呼叫，那麼需要配置稍多一些的worker程序。例如，如果業務方面會致使使用者請求大量讀取本地磁碟上的靜態資原始檔，而且伺服器上的記憶體較小，以至於大部分的請求訪問靜態資原始檔時都必須讀取磁碟（磁頭的定址是緩慢的），而不是記憶體中的磁碟快取，那麼磁碟I/O呼叫可能會阻塞住worker程序少量時間，進而導致服務整體效能下降。多worker程序可以充分利用多核系統架構，但若worker程序的數量多於CPU核心數，那麼會增大程序間切換帶來的消耗（Linux是搶佔式核心）。一般情況下，使用者要配置與CPU核心數相等的worker程序，並且使用下面的worker_cpu_affinity配置來繫結CPU核心。

（2）繫結Nginx worker程序到指定的CPU核心
語法： worker_cpu_affinity cpumask [cpumask...]
為什麼要繫結worker程序到指定的CPU核心呢？假定每一個worker程序都是非常繁忙的，如果多個worker程序都在搶同一個CPU，那麼這就會出現同步問題。反之，如果每一個worker程序都獨享一個CPU，就在核心的排程策略上實現了完全的併發。
例如，如果有4顆CPU核心，就可以進行如下配置：
worker_processes 4;
worker_cpu_affinity 1000 0100 0010 0001;
注意 ：worker_cpu_affinity配置僅對Linux作業系統有效。Linux作業系統使用sched_setaffinity()系統呼叫實現這個功能。

（3）Nginx worker程序優先順序設定
語法： worker_priority nice;
預設： worker_priority 0;
該配置項用於設定Nginx worker程序的nice優先順序。在Linux或其他類UNIX作業系統中，當許多程序都處於可執行狀態時，將按照所有程序的優先順序來決定本次核心選擇哪一個程序執行。程序所分配的CPU時間片大小也與程序優先順序相關，優先順序越高，程序分配到的時間片也就越大（例如，在預設配置下，最小的時間片只有5ms，最大的時間片則有800ms）。這樣，優先順序高的程序會佔有更多的系統資源。優先順序由靜態優先順序和核心根據程序執行情況所做的動態調整（目前只有±5的調整）共同決定。nice值是程序的靜態優先順序，它的取值範圍是–20~+19，–20是最高優先順序，+19是最低優先順序。因此，如果使用者希望Nginx佔有更多的系統資源，那麼可以把nice值配置得更小一些，但不建議比核心程序的nice值（通常為–5）還要小。

C、事件類配置項
下面是事件類配置項的相關介紹。
（1）是否開啟accept鎖
語法： accept_mutex [on|off]
預設： accept_mutext on;
accept_mutex是Nginx的負載均衡鎖，accept_mutex這把鎖可以讓多個worker程序輪流地、序列化地與新的客戶端建立TCP連線。當某一個worker程序建立的連線數量達到worker_connections配置的最大連線數的7/8時，會大大地減小該worker程序試圖建立新TCP連線的機會，以此實現所有worker程序之上處理的客戶端請求數儘量接近。accept鎖預設是開啟的，如果關閉它，那麼建立TCP連線的耗時會更短，但worker程序之間的負載會非常不均衡，因此不建議關閉它。

（2）選擇事件模型
語法： use [kqueue|rtsig|epoll|/dev/poll|select|poll|eventport];
預設： Nginx會自動使用最適合的事件模型。
對於Linux作業系統來說，可供選擇的事件驅動模型有poll、select、epoll三種。epoll當然是效能最高的一種。

（3）每個worker的最大連線數
語法： worker_connections number;
定義每個worker程序可以同時處理的最大連線數。