worker_processes

      worker_processes指令是用來設計Nginx進程數，官方默認設為1，賦值太多了，將會對系統IO影響效率，降低Nginx服務器性能。但是為了讓多核CPU能夠更好的處理并行任務，我們可以講該值設置大一些，最好這個值是機器CPU的倍數，并不是越大越好。
  worker_cpu_affinity

　　worker_cpu_affinity指令用來分配每個進程的CPU的工作內核 

 　　worker_processes 4 ; 四核開啟了四個進程 worker_cpu_affinity 0001 0010 0100 1000; //我們CPU 就是四核 就是四組值，0是不使用，1是使用。 這樣每一個進程都有一個 cpu內核了。 ｛解析 四組二進制值分別對應著四個進程，第一個進程對應的是0001 第二個進程對應的是0010，表示第二個進程計算器內核，第三個進程對應的是0100，表示第三個計算機內核，第四個進程對應1000｝　　

　　send_timeout

　　send_timeout  120s;

用于設置nginx服務器響應客戶端的超時時間，這個超時時間僅針對兩個客戶端和服務器之間建立連接后，某次活動之間的時間。如果這個時間后客戶端沒有任何活動，nginx服務器將會關閉連接

  keepalive_timeout

　　keepalive_timeout  160s

指定客戶端連接保持的超時時間，該設置表示nginx服務器與客戶端保持活動時間是60s，60s后服務器與客戶端斷開連接

　　client_header_buffer_size

　　client_header_buffer_size  4k;

　　　　設置nginx 服務器允許的客戶端請求頭部的緩沖區大小，默認為1KB。此指令的賦值可以根據系統分頁大小來設置。分頁大小也可以用“# getconf PAGESIZE”命令取得

有過nginx服務器工作經驗的朋友可能會遇到nginx 服務器返回400錯誤的情況，查找nginx服務器的400錯誤原因比較困難，因為此錯誤并不是每次都會出現，出現錯誤的時候，通常在瀏覽器和日志里也看不到任何有關提示信息。

根據實際經驗來看，有很大一部分情況是客戶端的請求頭部過大造成的。請求頭部過大，通常是客戶端cookie中寫入了較大的值引起的。于是適當增大此指令的賦值，允許nginx服務器接收較大的請求頭部，可以改善服務器對客戶端

的支持能力。一般將此指令設置為4KB.

　　client_header_timeout

　　client_header_timeout  20s;

　　設置讀取客戶端請求頭數據的超時時間。此處值是15s,為經驗參考值，默認是60s。

如果超過這個時間，客戶端還沒有發送完整的header數據，服務端將返回”Request timeout(408)”錯誤，

　　　multi_accept

　　　配置nginx服務器時候經可能多的接受客戶端的網絡連接請求,默認off

驅動相關指定　

　use

參數詳解：use指令用于指定Nginx服務器使用的事件驅動模型

　worker_connections

該指令用于設置Nginx服務器的每個工作進程允許同時連接客戶端的最大數量，語法為

worker_connections number;

結合worker_processes 指令，我們可以計算出Nginx 服務器允許同時練級的客戶端最大數量 Client=worker_processes * worker_connections / 2 。

在看一本書的過程中看到作者 在使用Nginx服務器的過程中遇到無法訪問Nginx 服務器的情況。查看日志信息發現一直報如下錯誤

他是怎么分析解決的呢： 

根據報錯信息，推測可能是Nginx 服務器的最大訪問鏈接數量設置小了。此指令設置的就是Nginx服務器能接受的最大訪問量，其中包括前端用戶鏈接也包括其他鏈接，這個值在理論上等于此指令的值與它允許開啟的工作進程最大數的乘積。 此指令一般為65535；

worker_connections 65535;

此指令的賦值與linux 操作系統中進程可以打開 的文件句柄數量有關系。按照以上設置修改了賦值以后，Nginx 服務器報如下錯誤：

究其原因，在linux 系統中有一個系統指令open file resource limit ，它設置了進程可以打開的文件句柄數量，worker_connections 指令的賦值不能超過 open file resource limit 的賦值可以使用以下的命令查看 linux 系統中 該指令的值

#  cat  /proc/sys/fs/file-max 

可以通過下面命令將open file resource limit 指令的值設為 2390251：

# echo “2390251” > /proc/sys/fs/file-max;  sysctl -p

這樣Nginx 的worker_connections 指令賦值65535 就沒問題了

worker_rlimit_sigpending 

參數詳解：該指令用于設置linux 2.6.6-mm2 版本之后的 linux 平臺的事件信號隊列長度上線。其語法結構為

worker_rlimit_sigpending  limit;

注：limit 為linux 平臺事件信號隊列的長度上限值。

該指令主要影響事件驅動模型中rtsig 模型可以保存的最大信號數。Nginx 服務器的每一個工作進程有自己的事件信號隊列用于存儲客戶端請求發生的信號，如果超過長度上限，nginx 服務器自動轉用poll 模型處理未處理的客戶端請求，為了保證Nginx 服務器對客戶端請求的高效處理，請大家根據實際的客戶端并發請求數量和服務器運行環境能力設定該值，設置示范

worker_rlimit_sifpending 1024;

devpoll_changes 和 devpoll_events 

參數詳解：這兩個指令用于設置在 /dev/poll 事件驅動模式下，Nginx服務器可以與內核之間傳遞事件的數量，前者設置傳遞給內核的事件數量，后者設置從內核獲取的事件數量，語法結構為：

devpoll_changes number;

devpoll_events number;

注：number 為要設置的數量，默認值為32.

kqueue_changes 和 kqueue_events 

參數詳解：這兩個指令用于設置在kqueue 時間驅動模式下，Nginx 服務器可以與內核之間傳遞事件的數量，前者設置傳遞給內核的事件數量，后者設置從內核獲取的事件數量，其語法結構為：

kqueue_changes number;

kqueue_events number;

注：number 為要設置的數量，默認值均為512。

epoll_events 

參數詳解：該指令用于設置在epoll 事件驅動模式下Nginx 服務器可以與內核之間傳遞事件的數量，與其他事件驅動模型不同，在epoll事件驅動模式下Nginx 服務器向內核傳遞事件的數量和從內核傳遞事件數量是相等得。因此沒有類似epoll_changes 這樣的指令,默認值為512.

 epoll_events 512;

 　　rtsig_signo

　　該指令用于設置rtsig模式使用兩個信號中的第一個,

　　rtsig_signo signo

rtsig_overfloe_* number

　　用于代表三個具體的指令 分別是:rtsig_overflow_events  rtsig_overflow_test

rtsig_over_thresold

　　rtsig_overflow_events:指定對壘米處時使用poll庫處理的事件數

rtsig_overflow_test: 指定poll庫處理地幾件事見后將清空rtsig模型使用的信號隊列,默認32

rtsig_over_thresold: 指定rtsig模式使用的信號隊列中的時間超過多少時就清空隊列