Core functionality.md

核心功能

在Nginx配置文件總能夠把配置文件的結構以下：

main配置段
            event {
                ...
            }
            http {
                ...
                server {
                    server_name
                    root 
                    location /uri/ {
                        ...
                    }
                }
                server {
                    ...
                }
            }

在Nginx中每一個參數都會有本身所在的Context，有的只能在指定的Context使用，而有的配置能夠在多個Context中使用。下面介紹的是main 段的和event端的相關配置。

main配置段

daemon

Syntax: daemon on | off;
Default:    daemon on;
Context:    main

肯定nginx是否應該成爲守護進程。 主要用於開發過程當中。

env

Syntax: env variable[=value];
Default:    env TZ;
Context:    main

默認狀況下，nginx刪除從其父進程繼承的全部環境變量，除了TZ變量。 此指令容許保留一些繼承的變量，更改其值或建立新的環境變量。 詳細參考

events

Syntax: events { ... }
Default:    —
Context:    main

提供配置文件上下文，其中指定了影響鏈接處理的指令。

load_module

Syntax: load_module file;
Default:    —
Context:    main
This directive appeared in version 1.9.11.

加載動態模塊。此僞指令出如今1.9.11版本中。

lock_file

Syntax: lock_file file;
Default:    lock_file logs/nginx.lock;
Context:    main

nginx使用鎖定機制來實現accept_mutex和序列化對共享內存的訪問。 在大多數系統上，鎖是使用原子操做實現的，而且此僞指令被忽略。

master_process

Syntax: master_process on | off;
Default:    master_process on;
Context:    main

是否以master/worker模型運行nginx；

pcre_jit

Syntax: pcre_jit on | off;
Default:    
pcre_jit off;
Context:    main
This directive appeared in version 1.1.12.

啓用或禁用對配置解析時間已知的正則表達式使用「即時編譯」（PCRE JIT）。
PCRE JIT能夠加速正則表達式的處理。
JIT在PCRE庫中可用，從使用--enable-jit配置參數構建的8.20版本開始。 當PCRE庫使用nginx（--with-pcre =）構建時，經過--with-pcre-jit配置參數啓用JIT支持。

pid

Syntax: pid file;
Default:    pid nginx.pid;
Context:    main

指定nginx進程的pid文件路徑；

ssl_engine

Syntax: ssl_engine device;
Default:    —
Context:    main

定義硬件SSL加速器的名稱。

thread_pool

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.

定義用於多線程讀取和發送文件的命名線程池，而不阻塞worker進程。

timer_resolution

Syntax: timer_resolution interval;
Default:    —
Context:    main

該配置指令容許用戶減小調用gettimeofday()的次數。默認狀況下，該函數在每次I/O端口監聽（好比epoll_wait）返回後都將被調用，而經過timer_resolution配置選項能夠直接指定調用gettimeofday()函數的間隔時間。

user

Syntax: user user [group];
Default:    user nobody nobody;
Context:    main

定義worker進程使用的用戶和組憑證。 若是省略group，則使用名稱等於user的組。

worker_cpu_affinity

Syntax: worker_cpu_affinity cpumask ...;
worker_cpu_affinity auto [cpumask];
Default:    —
Context:    main

將worker進程綁定到CPU核心。 每一個CPU核心由容許的CPU的位掩碼錶示。 應該爲每一個worker進程定義一個單獨的核心。 默認狀況下，worker進程不綁定到任何特定的CPU。
一個四核CPU能夠作以下配置：

worker_processes    4;
worker_cpu_affinity 0001 0010 0100 1000;

上面是綁定每一個worker 進程到指定的CPU上，而下面的：

worker_processes    2;
worker_cpu_affinity 0101 1010;

將第一個worker進程綁定到CPU0 / CPU2，將第二個worker進程綁定到CPU1 / CPU3。 第二個例子適用於超線程。
特殊值auto（1.9.10）容許將worker進程自動綁定到可用的CPU：

worker_processes auto;
worker_cpu_affinity auto;

worker_priority

Syntax: worker_processes number | auto;
Default:    worker_processes 1;
Context:    main

定義worker進程的調度優先級，就像由nice命令完成的：負數意味着更高的優先級。 容許範圍一般在-20到20之間變化。

worker_processes

Syntax: worker_processes number | auto;
Default:    worker_processes 1;
Context:    main

worker進程的個數；一般應該爲物理CPU核心數量減1；能夠爲"auto"，實現自動設定；

worker_rlimit_core

Syntax: worker_rlimit_core size;
Default:    —
Context:    main

更改worker進程最大核心文件大小（RLIMIT_CORE）的限制。用於在不從新啓動主進程的狀況下增長限制。

worker_rlimit_nofile

Syntax: worker_rlimit_nofile number;
Default:    —
Context:    main

更改worker進程最大打開文件數（RLIMIT_NOFILE）的限制。用於在不從新啓動主進程的狀況下增長限制。

working_directory

Syntax: working_directory directory;
Default:    —
Context:    main

定義worker進程的當前工做目錄。 它主要用於編寫核心文件，在這種狀況下，worker進程應該具備指定目錄的寫入權限。

event 配置段

accept_mutex

Syntax: accept_mutex on | off;
Default:    accept_mutex off;
Context:    events

各worker接收用戶的請求的負載均衡鎖；啓用時，表示用於讓多個worker輪流地、序列化地響應新請求； 不然，將向全部worker進程通知有關新鏈接的信息，若是新鏈接數量較少，則某些worker進程可能只會浪費系統資源。
在版本1.11.3以前，默認值爲on。

accept_mutex_delay

Syntax: accept_mutex_delay time;
Default:    accept_mutex_delay 500ms;
Context:    events

若是啓用accept_mutex，則指定若是另外一個worker進程當前正在接受新鏈接，worker進程將嘗試從新啓動接受新鏈接的最長時間。

multi_accept

Syntax: multi_accept on | off;
Default:    multi_accept off;
Context:    events

若是禁用multi_accept，worker進程將一次接受一個新鏈接。 不然，worker進程將一次接受全部新鏈接。

use

Syntax: use method;
Default:    —
Context:    events

指定要使用的鏈接處理方法。 一般不須要明確指定它，由於nginx將默認使用最有效的方法。

worker_aio_requests

Syntax: worker_aio_requests number;
Default:    worker_aio_requests 32;
Context:    events
This directive appeared in versions 1.1.4 and 1.0.7.

當使用帶有epoll鏈接處理方法的aio時，爲單個worker進程設置未完成的異步I / O操做的最大數量。

worker_connections

Syntax: worker_connections number;
Default:    worker_connections 512;
Context:    events

每一個worker進程所可以響應的最大併發請求數量；應該記住，這個數字包括全部鏈接（例如與代理服務器的鏈接等），而不單單是與客戶端的鏈接。 另外一個考慮是同時鏈接的實際數量不能超過打開文件的最大數量的當前限制，能夠經過worker_rlimit_nofile更改。
在nginx中設置的最大鏈接數爲：
worker_proceses * worker_connections

其餘

include

Syntax: include file | mask;
Default:    —
Context:    any

將另外一個文件或匹配指定掩碼的文件包含到配置中。 包含的文件應包含語法正確的指令和塊。

error_log

Syntax: error_log file [level];
Default:    error_log logs/error.log error;
Context:    main, http, mail, stream, server, location

配置日誌記錄。 第一個參數定義將存儲日誌的文件。 第二個參數肯定日誌記錄的級別，能夠是如下之一：debug，info，notice，warn，error，crit，alert或emerg。 以上的日誌級別按嚴重性遞增的順序列出。 設置特定日誌級別將致使記錄指定日誌級別和更嚴重日誌級別的全部消息。 例如，默認級別error將致使記錄錯誤，crit，alert和emerg消息。 若是省略此參數，則使用error。 出於調試的須要，能夠設定爲debug；但debug僅在編譯時使用了「--with-debug」選項時纔有效；