Nginx 靜態文件服務配置及優化

原文連接： 何曉東 博客

根目錄和索引文件

root 指令指定將用於搜索文件的根目錄。 爲了獲取所請求文件的路徑，NGINX 將請求 URI 附加到 root 指令指定的路徑。該指令能夠放在 http {}，server {} 或 location {} 上下文中的任何級別。在下面的示例中，爲虛擬服務器定義了 root 指令。 它適用於未包含根指令的全部location {} 塊，以顯式從新定義根：

server {
    root /www/data;

    location / {
    }

    location /images/ {
    }

    location ~ \.(mp3|mp4) {
        root /www/media;
    }
}

在這裏，NGINX 針對 /images/ 開頭的 URI 將在文件系統的 /www/ data/images/ 目錄中搜索相應文件。 若是 URI 以 .mp3 或 .mp4 擴展名結尾，則 NGINX 會在 /www/media/ 目錄中搜索該文件，由於它是在匹配的位置塊中定義的。

若是請求以 / 結尾，則 NGINX 將其視爲對目錄的請求，並嘗試在目錄中查找索引文件。index 指令定義索引文件的名稱（默認值爲 index.html）。要繼續該示例，若是請求 URI 是 /images/some/path/，則 NGINX 會返回文件 /www/data/images/some/path/index.html（若是存在）。若是沒有，NGINX 默認返回 HTTP 404 錯誤（未找到）。要配置 NGINX 以返回自動生成的目錄列表，請在 autoindex 指令中包含 on 參數：

location /images/ {
    autoindex on;
}

你能夠在 index 指令中列出多個文件名。 NGINX按指定的順序搜索文件並返回它找到的第一個文件。

location / {
    index index.$geo.html index.htm index.html;
}

這裏使用的 $geo 變量是經過 geo 指令設置的自定義變量。變量的值取決於客戶端的 IP 地址。

要返回索引文件，NGINX 會檢查它是否存在，而後對經過將索引文件的名稱附加到基礎 URI 上得到的新 URI 進行內部重定向。內部重定向致使對位置的新搜索，而且可能最終位於另外一個位置，如如下示例所示：

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 將映射到第二個位置。結果，請求被代理。

嘗試幾種選擇

try_files 指令可用於檢查指定的文件或目錄是否存在; NGINX 會進行內部重定向，若是沒有，則返回指定的狀態代碼。例如，要檢查對應於請求 URI 的文件是否存在，請使用 try_files指令和 $uri 變量，以下所示：

server {
    root /www/data;

    location /images/ {
        try_files $uri /images/default.gif;
    }
}

該文件以 URI 的形式指定，使用在當前位置或虛擬服務器的上下文中設置的根或別名指令進行處理。在這種狀況下，若是對應於原始 URI 的文件不存在，NGINX 會將內部重定向到最後一個參數指定的 URI，並返回 /www/data/images/default.gif。

最後一個參數也能夠是狀態代碼（直接以等號開頭）或位置名稱。 在如下示例中，若是 try_files 指令的全部參數都不會解析爲現有文件或目錄，則會返回 404 錯誤。

location / {
    try_files $uri $uri/ $uri.html =404;
}

在下一個示例中，若是原始 URI 和帶有附加尾部斜槓的 URI 都不會解析爲現有文件或目錄，則會將請求重定向到指定位置，並將其傳遞給代理服務器。

location / {
    try_files $uri $uri/ @backend;
}

location @backend {
    proxy_pass http://backend.example.com;
}

有關更多信息，請觀看內容緩存網絡研討會，瞭解如何顯着提升網站性能，並深刻了解 NGINX 的緩存功能。

優化服務內容的性能

加載速度是提供任何內容的關鍵因素。 對 NGINX 配置進行微小優化能夠提升生產力並幫助實現最佳性能。

啓用 sendfile

默認狀況下，NGINX 會自行處理文件傳輸，並在發送以前將文件複製到緩衝區中。 啓用 sendfile 指令消除了將數據複製到緩衝區的步驟，並容許將數據從一個文件描述符直接複製到另外一個文件描述符。或者，爲了防止一個快速鏈接徹底佔用工做進程，可使用 sendfile_max_chunk 指令限制單個sendfile() 調用中傳輸的數據量（在本例中爲1 MB）：

location /mp3 {
    sendfile           on;
    sendfile_max_chunk 1m;
    #...

}

啓用 tcp_nopush

將 tcp_nopush 指令與 sendfile on; 指令一塊兒使用。這使得 NGINX 能夠在 sendfile() 獲取數據塊以後當即在一個數據包中發送 HTTP 響應頭。

location /mp3 {
    sendfile   on;
    tcp_nopush on;
    #...

}

啓用 tcp_nodelay

tcp_nodelay 指令容許覆蓋 Nagle 的算法，該算法最初設計用於解決慢速網絡中小數據包的問題。該算法將許多小數據包合併爲一個較大的數據包，並以 200 毫秒的延遲發送數據包。現在，在提供大型靜態文件時，不管數據包大小如何，均可以當即發送數據。延遲也會影響在線應用程序（ssh，在線遊戲，在線交易等）。默認狀況下，tcp_nodelay 指令設置爲 on，這意味着禁用了 Nagle的算法。此指令僅用於 keepalive 鏈接：

location /mp3  {
    tcp_nodelay       on;
    keepalive_timeout 65;
    #...
    
}

優化積壓隊列

其中一個重要因素是 NGINX 能夠多快地處理傳入鏈接。通常規則是在創建鏈接時，將其放入偵聽套接字的 "listen" (監聽)隊列中。在正常負載下，隊列很小或根本沒有隊列。可是在高負載下，隊列會急劇增加，致使性能不均勻，鏈接中斷，延遲增長。

顯示積壓隊列

使用命令 netstat -Lan 來顯示當前監聽隊列。輸出可能以下所示，它顯示在端口 80上的監聽隊列中，有 10 個未接受的鏈接，這些鏈接針對配置的最多 128 個排隊鏈接。這種狀況很正常。

Current listen queue sizes (qlen/incqlen/maxqlen)
Listen         Local Address         
0/0/128        *.12345            
10/0/128        *.80       
0/0/128        *.8080

相反，在如下命令中，未接受的鏈接數（192）超過了 128 的限制。當網站流量很大時，這種狀況很常見。要得到最佳性能，須要在操做系統和 NGINX 配置中增長能夠排隊等待 NGINX 接受的最大鏈接數。

Current listen queue sizes (qlen/incqlen/maxqlen)
Listen         Local Address         
0/0/128        *.12345            
192/0/128        *.80       
0/0/128        *.8080

調整操做系統

將 net.core.somaxconn 內核參數的值從其默認值（128）增長到足以容納大量流量的值。在這個例子中，它增長到 4096。

• FreeBSD 的命令爲 sudo sysctl kern.ipc.somaxconn=4096
• Linux 的命令爲 1. sudo sysctl -w net.core.somaxconn=4096 2. 將 net.core.somaxconn = 4096 加入到 /etc/sysctl.conf 文件中。

調整 NGINX

若是將 somaxconn 內核參數設置爲大於 512 的值，請將 backlog 參數增長在 NGINX listen 指令以匹配修改：

server {
    listen 80 backlog=4096;
    # ...

}

© 文章翻譯自 Nginx Serving Static Content，部分作了語義調整。

大佬，知識就是力量，來 獲取更多力量吧，謝謝啦。