本節(jié)介紹如何使用NGINX來提供靜態(tài)內(nèi)容服務(wù),定義搜索路徑以查找請求的文件的方法,以及如何設(shè)置索引文件。
在這個部分,我們主要涉及以下幾個方面的內(nèi)容:
root指令指定將用于搜索文件的根目錄。 要獲取請求文件的路徑,NGINX將請求URI附加到root指令指定的路徑。 該指令可以放置在http,server或location上下文中的任何級別上。 在下面的示例中,為虛擬服務(wù)器定義了root指令。 它適用于不包括root指令的所有location塊以顯式重新定義根:
server {
root /www/data;
location / {
}
location /images/ {
}
location ~ \.(mp3|mp4) {
root /www/media;
}
}
這里,NGINX在文件系統(tǒng)的/www/data/images/目錄中搜索以/images/開頭的URI。 但是,如果URI以.mp3或.mp4擴展名結(jié)尾,則NGINX會在/www/media/目錄中搜索.mp3或.mp4文件,因為它在匹配的location塊中定義。
如果請求以斜杠結(jié)尾,則NGINX將其視為對目錄的請求,并嘗試在目錄中找到索引文件。index指令定義索引文件的名稱(默認值為index.html)。繼續(xù)示例,如果請求URI為/images/some/path/,則NGINX會傳遞文件/www/data/images/some/path/index.html(如果存在)。 如果不存在文件,NGINX默認返回HTTP代碼404(未找到)。 要配置NGINX以返回自動生成的目錄列表,請將on參數(shù)添加到autoindex指令中:
location /images/ {
autoindex on;
}
可以在索引指令中列出多個文件名。 NGINX以指定的順序搜索文件,并返回它找到的第一個文件。
location / {
index index.$geo.html index.html index.html;
}
這里使用的$geo變量是通過geo指令設(shè)置的自定義變量。 變量的值取決于客戶端的IP地址。
要返回索引文件,NGINX檢查其是否存在,然后通過將索引文件的名稱附加到基本URI來對通過URI獲取的內(nèi)部重定向。內(nèi)部重定向會導致對某個位置(location)的新搜索,并且可能會在另一個位置(location)中結(jié)束,如以下示例所示:
location / {
root /data;
index index.html index.php;
}
location ~ \.php {
fastcgi_pass localhost:8000;
...
}
在這里,如果請求中的URI是/path/,并且/data/path/index.html不存在,但是/data/path/index.php存在,則將/path/index.php 內(nèi)部重定向映射到第二個位置(location)。 因此,請求被代理。
try_files指令可用于檢查指定的文件或目錄是否存在并進行內(nèi)部重定向,如果沒有指定的文件或目錄,則返回特定的狀態(tài)代碼。 例如,要檢查與請求URI相對應(yīng)的文件的存在,請使用try_files指令和$uri變量,如下所示:
server {
root /www/data;
location /images/ {
try_files $uri /images/default.gif;
}
}
該文件以URI的形式指定,它使用在當前位置或虛擬服務(wù)器的上下文中設(shè)置的 root 或 alias 偽指令進行處理。 在這種情況下,如果與原始URI相對應(yīng)的文件不存在,則NGINX將內(nèi)部重定向到最后一個參數(shù)中指定的URI,也就是返回/www/data/images/default.gif。
最后一個參數(shù)也可以是一個狀態(tài)代碼(直接在前面的等號)或位置的名稱。 在以下示例中,如果try_files指令的任何參數(shù)都不會解析為現(xiàn)有文件或目錄,則會返回404錯誤。
location / {
try_files $uri $uri/ $uri.html =404;
}
在下一個示例中,如果原始URI和帶有附加尾部斜線的URI都不能解析為現(xiàn)有文件或目錄,則將請求重定向到將其傳遞給代理服務(wù)器的命名位置(location)。
location / {
try_files $uri $uri/ @backend;
}
location @backend {
proxy_pass http://backend.example.com;
}
加載速度是服務(wù)任何內(nèi)容的關(guān)鍵因素。 對您的NGINX配置進行小幅優(yōu)化可能會提高生產(chǎn)力并幫助實現(xiàn)最佳性能。
默認情況下,NGINX會自動處理文件傳輸,并在發(fā)送文件之前將其復(fù)制到緩沖區(qū)中。 啟用sendfile指令將消除將數(shù)據(jù)復(fù)制到緩沖區(qū)中的步驟,并允許將數(shù)據(jù)從一個文件描述符直接復(fù)制到另一個文件描述符。 或者,為了防止一個快速連接完全占用工作進程,您可以通過定義sendfile_max_chunk指令來限制在單個sendfile()調(diào)用中傳輸?shù)臄?shù)據(jù)量:
location /mp3 {
sendfile on;
sendfile_max_chunk 1m;
...
}
將tcp_nopush選項與sendfile一起使用。 該選項將使NGINX能夠通過sendfile獲取數(shù)據(jù)塊之后,在一個數(shù)據(jù)包中發(fā)送HTTP響應(yīng)頭
location /mp3 {
sendfile on;
tcp_nopush on;
...
}
tcp_nodelay選項可以覆蓋Nagle的算法,最初是為了解決慢網(wǎng)絡(luò)中的小數(shù)據(jù)包問題而設(shè)計的。 該算法將大量小數(shù)據(jù)包整合到較大的數(shù)據(jù)包中,并以200 ms的延遲發(fā)送數(shù)據(jù)包。
如今,當服務(wù)大型靜態(tài)文件時,無論數(shù)據(jù)包大小如何,都可以立即發(fā)送數(shù)據(jù)。 延遲也會影響在線應(yīng)用程序(ssh,在線游戲,網(wǎng)上交易)。 默認情況下,tcp_nodelay指令設(shè)置為on,表示Nagle的算法被禁用。 該選項僅用于Keepalive連接:
location /mp3 {
tcp_nodelay on;
keepalive_timeout 65;
...
}
其中一個重要因素是NGINX可以處理傳入連接的速度。 一般規(guī)則是建立連接時,將其放入監(jiān)聽套接字的“偵聽”隊列中。 在正常負載下,有一個低隊列,或根本沒有隊列。 但是在高負載下,隊列可能會急劇增長,這可能會導致性能不均衡,連接丟失和延遲。
測量偵聽隊列
讓我們來查看當前的偵聽隊列。 運行命令:
netstat -Lan
命令輸出可能如下所示:
Current listen queue sizes (qlen/incqlen/maxqlen)
Listen Local Address
0/0/128 *.12345
10/0/128 *.80
0/0/128 *.8080
命令輸出顯示端口80的監(jiān)聽隊列中有10個不接受的連接,而連接限制為128個連接,這種情況是正常的。
但是,命令輸出可能如下所示:
Current listen queue sizes (qlen/incqlen/maxqlen)
Listen Local Address
0/0/128 *.12345
192/0/128 *.80
0/0/128 *.8080
命令輸出顯示超過128個連接限制的192個不可接受的連接。 當網(wǎng)站的流量很大時,這是很常見的。 為了達到最佳性能,您需要增加NGINX在操作系統(tǒng)和NGINX配置中排隊等待接收的最大連接數(shù)。
調(diào)整操作系統(tǒng)
將net.core.somaxconn鍵的值從其默認值(128)增加到足夠高的值以能夠處理高突發(fā)流量:
對于FreeBSD,運行命令:
sudo sysctl kern.ipc.somaxconn=4096
對于FreeBSD,運行命令:
sudo sysctl -w net.core.somaxconn=4096
打開文件:/etc/sysctl.conf,將下面一行添加到文件并保存文件:
net.core.somaxconn = 4096
調(diào)整NGINX
如果將somaxconn鍵設(shè)置為大于512的值,請更改NGINX listen指令的backlog參數(shù)以匹配:
server {
listen 80 backlog 4096;
# The rest of server configuration
}