天天看點
傳回

Nginx讀書筆記三----資源配置設定

Nginx讀書筆記三----資源配置設定

1、記憶體及磁盤資源配置設定

1.1 在磁盤中存儲HTTP請求體 

文法： client_body_in_file_only on|clean|off; 

預設： client_body_in_file_only off; 

配置塊： http、 server、 location

當值為非off時， 使用者請求中的HTTP包體一律存儲到磁盤檔案中， 即使隻有0位元組也會存儲為檔案。

當請求結束時，如果配置為on，則這個檔案不會被删除（該配置一般用于調試、定位問題），但如果配置為clean，則會删除該檔案。 

 1.2 HTTP包體盡量寫入到一個記憶體buffer中  

文法：client_body_in_single_buffer on|off;

預設：client_body_in_single_buffer off;

配置塊：http、server、location

使用者請求中的HTTP包體一律存儲到記憶體buffer中。當然，如果HTTP包體的大小超過了下面client_body_buffer_size設定的值，包體還是會寫入到磁盤檔案中。

1.3 存儲HTTP頭部的記憶體buffer大小 

文法：client_header_buffer_size size;

預設：client_header_buffer_size 1k;

配置塊：http、server

上面配置項定義了正常情況下Nginx接收使用者請求中HTTP header部分（包括HTTP行和HTTP頭部）時配置設定的記憶體buffer大小。有時，請求中的HTTP header部分可能會超過這個大小，這時large_client_header_buffers定義的buffer将會生效。

1.4 存儲超大HTTP頭部的記憶體buffer大小 

文法：large_client_header_buffers number size;

預設：large_client_header_buffers 4 8k;

配置塊：http、server

large_client_header_buffers定義了Nginx接收一個超大HTTP頭部請求的buffer個數和每個buffer的大小。如果HTTP請求行（如GET/index HTTP/1.1）的大小超過上面的單個buffer，則傳回"Request URI too large"(414)。請求中一般會有許多header，每一個header的大小也不能超過單個buffer的大小，否則會傳回"Bad request

(400)。當然，請求行和請求頭部的總和也不可以超過 buffer個數 * buffer 大小。

1.5 存儲HTTP包體的記憶體buffer大小 

文法：client_body_buffer_size size;

預設：client_body_buffer_size 8k/16k;

配置塊：http、server、location

上面配置項定義了Nginx接收HTTP包體的記憶體緩沖區大小。也就是說，HTTP包體會先接收到指定的這塊緩存中，之後才決定是否寫入磁盤。

注意：如果使用者請求中含有HTTP頭部Content-Length，并且其辨別的長度小于定義的buffer大小，那麼Nginx會自動降低本次請求所使用的記憶體buffer，以降低記憶體消耗。

client_max_body_size 

文法: client_max_body_size size;

預設: client_max_body_size 1m;

配置塊: http, server, location

設定用戶端請求主體的最大允許大小，在“Content-Length”請求頭字段中指定。如果請求中的大小超過了配置值，則将413（請求實體過大）錯誤傳回給用戶端。請注意浏覽器不能正确顯示此錯誤。将大小設定為0禁用用戶端請求主體大小的檢查。

浏覽器在發送含有較大HTTP包體的請求時， 其頭部會有一個Content-Length字段，client_max_body_size是用來限制Content-Length所示值的大小的。 是以， 這個限制包體的配置非常有用處， 因為不用等Nginx接收完所有的HTTP包體——這有可能消耗很長時間——就可以告訴使用者請求過大不被接受。例如， 使用者試圖上傳一個10GB的檔案， Nginx在收完標頭後， 發現Content-Length超過client_max_body_size定義的值， 就直接發送413("Request EntityToo Large")響應給用戶端。

1.6 HTTP包體的臨時存放目錄 

文法：client_body_temp_path dir-path[level1[level2[level3]]]

預設：client_body_temp_path client_body_temp;

配置塊：http、server、location

上面配置項定義HTTP包體存放的臨時目錄。在接收HTTP包體時，如果包體的大小大于client_body_buffer_size，則會以一個遞增的整數命名并存放到client_body_temp_path指定的目錄中。後面跟着的level1、level2、level3，是為了防止一個目錄下的檔案數量太多，進而導緻性能下降，是以使用了level參數，這樣可以按照臨時

件名最多再加三層目錄。例如：client_body_temp_pathoptnginx/client_temp 1 2;如果新上傳的HTTP包體使用00000123456作為臨時檔案名，就會被存放在這個目錄中。optnginx/client_temp/6/45/00000123456

1.7 connection_pool_size 

文法：connection_pool_size size;

預設： connection_pool_size 256;

配置塊： http、 server

Nginx對于每個建立成功的TCP連接配接會預先配置設定一個記憶體池，上面的size配置項将指定這個記憶體池的初始大小（即ngx_connection_t結構體中的pool記憶體池初始大小，），用于減少核心對于小塊記憶體的配置設定次數。需慎重設定，因為更大的size會使伺服器消耗的記憶體增多，而更小的size則會引

更多的記憶體配置設定次數。一般不設定

1.8 request_pool_size 

文法：request_pool_size size;

預設：request_pool_size 4k;

配置塊：http、server

Nginx開始處理HTTP請求時，将會為每個請求都配置設定一個記憶體池，size配置項将指定這個記憶體池的初始大小（即ngx_http_request_t結構體中的pool記憶體池初始大小），用于減少核心對于小塊記憶體的配置設定次數。TCP連接配接關閉時會銷毀connection_pool_size指定的連接配接記憶體池，HTTP請求結束

會銷毀request_pool_size指定的HTTP請求記憶體池，但它們的建立、銷毀時間并不一緻，因為一個TCP連接配接可能被複用于多個HTTP請求。

2、網絡連接配接設定

2.1 讀取HTTP頭部的逾時時間 

文法：client_header_timeout time（預設機關：秒）;

預設：client_header_timeout 60;

配置塊：http、server、location

用戶端與伺服器建立連接配接後将開始接收HTTP頭部，在這個過程中，如果在一個時間間隔（逾時時間）内沒有讀取到用戶端發來的位元組，則認為逾時，并向用戶端傳回408( " Request timed out " )響應。

2.2 讀取HTTP包體的逾時時間 

文法：client_body_timeout time（預設機關：秒）；

預設：client_body_timeout 60;

配置塊：http、server、location

此配置項與client_header_timeout相似，隻是這個逾時時間隻在讀取HTTP包體時才有效。如果逾時，同樣報408( " Request timed out " )響應

2.3 發送響應的逾時時間 

文法：send_timeout time;

預設：send_timeout 60;

配置塊：http、server、location

這個逾時時間是發送響應的逾時時間，即Nginx伺服器向用戶端發送了資料包，但用戶端一直沒有去接收這個資料包。如果某個連接配接超過send_timeout定義的逾時時間，那麼Nginx将會關閉這個連接配接。

2.4 lingering_close 

文法：lingering_close off|on|always;

預設：lingering_close on;

配置塊：http、server、location

該配置控制Nginx關閉使用者連接配接的方式。always表示關閉使用者連接配接前必須無條件地處理連接配接上所有使用者發送的資料。off表示關閉連接配接時完全不管連接配接上是否已經有準備就緒的來自使用者的資料。on是中間值，一般情況下在關閉連接配接前都會處理連接配接上的使用者發送的資料，除了有些情況下在業務上認定這之後的資料是不必要的。

2.5 lingering_time 

文法：lingering_time time;

預設：lingering_time 30s;

配置塊：http、server、location

lingering_close啟用後，這個配置項對于上傳大檔案很有用。上文講過，當使用者請求的 Content-Length大于max_client_body_size配置時，Nginx服務會立刻向使用者發送413（Requestentity too large）響應。

但是，很多用戶端可能不管413傳回值，仍然持續不斷地上傳HTTP body，這時，經過了lingering_time設定的時間後，Nginx将不管使用者是否仍在上傳，都會把連接配接關閉掉。

2.6 lingering_timeout 

文法：lingering_timeout time;

預設：lingering_timeout 5s;

配置塊：http、server、location

lingering_close生效後，在關閉連接配接前，會檢測是否有使用者發送的資料到達伺服器，如果超過lingering_timeout時間後還沒有資料可讀，就直接關閉連接配接；否則，必須在讀取完連接配接緩沖區上的資料并丢棄掉後才會關閉連接配接。

2.8 對某些浏覽器禁用keepalive功能 

文法：keepalive_disable[msie6|safari|none]...

預設：keepalive_disablemsie6 safari

配置塊：http、server、location

HTTP請求中的keepalive功能是為了讓多個請求複用一個HTTP長連接配接，這個功能對伺服器的性能提高是很有幫助的。但有些浏覽器，如IE 6和Safari，它們對于使用keepalive功能的POST請求處理有功能性問題。是以，針對IE 6及其早期版本、Safari浏覽器預設是禁用keepalive功能的。

2.9 keepalive逾時時間 

文法：keepalive_timeout time（預設機關：秒）;

預設：keepalive_timeout 75;

配置塊：http、server、location

一個keepalive連接配接在閑置超過一定時間後（預設的是75秒），伺服器和浏覽器都會去關閉這個連接配接。當然，keepalive_timeout配置項是用來限制Nginx伺服器的，Nginx也會按照規範把這個時間傳給浏覽器，但每個浏覽器對待keepalive的政策有可能是不同的。，MSIE關閉保持活動連接配接為60秒

2.10 一個keepalive長連接配接上允許承載的請求最大數 

文法：keepalive_requests n;

預設：keepalive_requests 100;

配置塊：http、server、location

一個keepalive連接配接上預設最多隻能發送100個請求。

2.11 tcp_nodelay 

文法：tcp_nodelay on|off;

預設：tcp_nodelay on;

配置塊：http、server、location

确定對keepalive連接配接是否使用TCP_NODELAY選項。它在SSL連接配接上啟用，用于無緩沖的代理，以及用于WebSocket代理。

2.12 tcp_nopush 

文法：tcp_nopush on|off;

預設：tcp_nopush off;

配置塊：http、server、location

在打開sendfile選項時，确定是否開啟FreeBSD系統上的TCP_NOPUSH或Linux系統上的TCP_CORK功能。打開tcp_nopush後，将會在發送響應時把整個響應標頭放到一個TCP包中發送。

3、對用戶端請求的限制

3.1 按HTTP方法名限制使用者請求 

文法： limit_except method...{...}
配置塊： location

Nginx通過limit_except後面指定的方法名來限制使用者請求。 方法名可取值包括： GET、HEAD、 POST、 PUT、 DELETE、 MKCOL、 COPY、 MOVE、 OPTIONS、 PROPFIND、PROPPATCH、 LOCK、 UNLOCK或者PATCH。 例如：

limit_except GET {

        allow 192.168.1.0/32;

        deny all;

    }

注意， 允許GET方法就意味着也允許HEAD方法。 是以， 上面這段代碼表示的是禁止GET方法和HEAD方法， 但其他HTTP方法是允許的。

3.2 對請求的限速 

文法： limit_rate speed;

預設： limit_rate 0;

配置塊： http、 server、 location、 if

此配置是對用戶端請求限制每秒傳輸的位元組數。 speed可以使用多種機關， 預設參數為0， 表示不限速。針對不同的用戶端， 可以用$limit_rate參數執行不同的限速政策。 例如：

server {

        if ($slow) {

            set $limit_rate 4k;

        }

    }

3.3 limit_rate_after 

文法： limit_rate_after time;

預設： limit_rate_after 1m;

配置塊： http、 server、 location、 if

此配置表示Nginx向用戶端發送的響應長度超過limit_rate_after後才開始限速。 例如：

limit_rate_after 1m;

limit_rate 100k；

4、檔案操作的優化配置項

4.1 sendfile系統調用 

文法： sendfile on|off;

預設： sendfile off;

配置塊： http、 server、 location

可以啟用Linux上的sendfile系統調用來發送檔案， 它減少了核心态與使用者态之間的兩次記憶體複制， 這樣就會從磁盤中讀取檔案後直接在核心态發送到網卡裝置， 提高了發送檔案的效率。

4.2 打開檔案緩存 

文法： open_file_cache max=N[inactive=time]|off;

預設： open_file_cache off;

配置塊： http、 server、 location

檔案緩存會在記憶體中存儲以下3種資訊：

  1. 檔案句柄、 檔案大小和上次修改時間。
  2. 已經打開過的目錄結構。
  3. 沒有找到的或者沒有權限操作的檔案資訊。

這樣， 通過讀取緩存就減少了對磁盤的操作。該配置項後面跟3種參數。

  • max： 表示在記憶體中存儲元素的最大個數。 當達到最大限制數量後， 将采用LRU（Least Recently Used） 算法從緩存中淘汰最近最少使用的元素。
  • inactive： 表示在inactive指定的時間段内沒有被通路過的元素将會被淘汰。 預設時間為60秒。
  • off： 關閉緩存功能。

例如：

open_file_cache max=1000 inactive=20s;

4.3 是否緩存打開檔案錯誤的資訊 

文法： open_file_cache_errors on|off;

預設： open_file_cache_errors off;

配置塊： http、 server、 location

此配置項表示是否在檔案緩存中緩存打開檔案時出現的找不到路徑、 沒有權限等錯誤資訊。

4.4 不被淘汰的最小通路次數 

文法： open_file_cache_min_uses number;

預設： open_file_cache_min_uses 1;

配置塊： http、 server、 location

它與open_file_cache中的inactive參數配合使用。 如果在inactive指定的時間段内， 通路次數超過了open_file_cache_min_uses指定的最小次數， 那麼将不會被淘汰出緩存。

（8） 檢驗緩存中元素有效性的頻率

文法： open_file_cache_valid time;

預設： open_file_cache_valid 60s;

配置塊： http、 server、 location

預設為每60秒檢查一次緩存中的元素是否仍有效。

5、對用戶端請求的特殊處理

5.1 忽略不合法的HTTP頭部 

文法： ignore_invalid_headers on|off;

預設： ignore_invalid_headers on;

配置塊： http、 server

如果将其設定為off， 那麼當出現不合法的HTTP頭部時， Nginx會拒絕服務， 并直接向使用者發送400（Bad Request） 錯誤。如果将其設定為on， 則會忽略此HTTP頭部。

5.2 HTTP頭部是否允許下劃線文法： underscores_in_headers on|off; 

預設： underscores_in_headers off;

配置塊： http、 server

預設為off， 表示HTTP頭部的名稱中不允許帶“_”（下劃線） 。

5.3 對If-Modified-Since頭部的處理政策 

文法： if_modified_since[off|exact|before];

預設： if_modified_since exact;

配置塊： http、 server、 location

出于性能考慮， Web浏覽器一般會在用戶端本地緩存一些檔案， 并存儲當時擷取的時間。 這樣， 下次向Web伺服器擷取緩存過的資源時， 就可以用If-Modified-Since頭部把上次擷取的時間捎帶上， 而if_modified_since将根據後面的參數決定如何處理If-Modified-Since頭部。

相關參數說明如下。

  • off： 表示忽略使用者請求中的If-Modified-Since頭部。 這時， 如果擷取一個檔案， 那麼會正常地傳回檔案内容。 HTTP響應碼通常是200。
  • exact： 将If-Modified-Since頭部包含的時間與将要傳回的檔案上次修改的時間做精确比較， 如果沒有比對上， 則傳回200和檔案的實際内容， 如果比對上， 則表示浏覽器緩存的檔案内容已經是最新的了， 沒有必要再傳回檔案進而浪費時間與帶寬了， 這時會傳回304 Not Modified， 浏覽器收到後會直接讀取自己的本地緩存。
  • before： 是比exact更寬松的比較。 隻要檔案的上次修改時間等于或者早于使用者請求中的If-Modified-Since頭部的時間， 就會向用戶端傳回304 Not Modified。

5.4 傳回錯誤頁面時是否在Server中注明Nginx版本 

文法： server_tokens on|off;

預設： server_tokens on;

配置塊： http、 server、 location

表示處理請求出錯時是否在響應的Server頭部中标明Nginx版本， 這是為了友善定位問題

上一篇: AndroidのListView包含CheckBox時滑動丢失選中狀态的解決AndroidのListView包含CheckBox時滑動丢失選中狀态的解決
下一篇: mysql資料庫縮容