NGINX 快取技術最佳化網站效能

現代網站效能瓶頸常源於後端伺服器處理重複請求的負擔。NGINX 提供強大的快取機制，能有效降低伺服器壓力，提升網站載入速度和使用者經驗。透過組態 proxy_cache_path 和 proxy_cache 等指令，能將靜態檔案、API 回應等快取至本地，減少後端伺服器的負載。微快取技術則適用於動態內容，透過短時間快取降低伺服器壓力。此外，NGINX 也支援快取控制、失效策略設定，以及多硬碟快取組態，滿足不同網站的效能需求。

高效能快取技術：使用 NGINX 與 NGINX Plus 最佳化網站效能

在現代網路環境中，網站效能對於企業的成功至關重要。使用者對於網站載入速度的期望越來越高，根據研究顯示，網站載入時間每增加100毫秒，可能導致收入下降1%。本文將探討如何利用 NGINX 與 NGINX Plus 的快取功能來提升網站效能。

為什麼頁面載入速度如此重要？

多年來，分析師一直在研究使用者行為，並提出了「N秒規則」，即使用者願意等待頁面載入和渲染的時間。隨著技術的進步和使用者期望的提高，這個時間不斷縮短：

• 1997年：Jakob Nielsen 提出10秒規則
• 2001年：Zona Research 提出8秒規則
• 2006年：Jupiter Research 提出4秒規則
• 2010年：PhocusWright 提出3秒規則

Google 也改變了遊戲規則。隨著 Google Instant Search 的推出，使用者在輸入搜尋詞時，甚至在完成輸入之前，就能看到候選搜尋結果。這表明了現代網路對速度的要求。

網站效能不佳的代價

網站效能不佳可能會對業務產生重大影響：

• 廣告點選率下降：Google 發現，其搜尋頁面載入時間每增加半秒，廣告點選率就會下降20%。
• 收入下降：亞馬遜進行了一項實驗，故意增加頁面載入時間，每次增加100毫秒，結果發現收入下降了1%。

Google 現在在計算頁面排名時也會考慮頁面載入速度。頁面載入的第一位元組時間越長，頁面排名受到的懲罰就越嚴重。

NGINX 快取技術與您的網站

NGINX 的快取功能可以顯著提升終端使用者的體驗，減少第一位元組的時間，使網頁內容感覺更流暢、更具回應性。NGINX 廣泛用於主要內容分發網路（CDN）的核心架構中。

快取的優勢：

1. 提升終端使用者效能
2. 簡化網站基礎架構
3. 提高應用伺服器的可用性，透過將快取工作從應用伺服器解除安裝
4. 隔離伺服器故障

NGINX 可以透過從上游伺服器解除安裝重複性任務來增加伺服器容量。即使對於看似無法快取的內容（例如部落格首頁），微快取（micro-caching）也非常有用——將內容在 NGINX 代理上快取一秒鐘或更短時間。當一百個使用者在同一秒內請求相同內容時，NGINX 可以將請求減少到對原始伺服器的單一請求，並從快取中向其他99個使用者提供內容。

程式碼範例：基本快取組態

http {
    proxy_cache_path /data/nginx/cache levels=1:2 keys_zone=my_cache:10m max_size=10g;
    server {
        location / {
            proxy_pass http://upstream;
            proxy_cache my_cache;
            proxy_cache_valid 200 1h;
            proxy_cache_revalidate on;
        }
    }
}

內容解密：

此組態設定了一個名為 my_cache 的快取區域，用於儲存來自上游伺服器的回應。快取的有效性設定為1小時，並且啟用了快取重新驗證功能，以確保快取內容的新鮮度。

微快取技術

微快取是一種特殊的快取策略，適用於那些看似無法快取的動態內容。透過將內容快取很短的時間（例如1秒），可以顯著減少對上游伺服器的請求數量，從而提升效能。

微快取組態範例

http {
    proxy_cache_path /data/nginx/cache levels=1:2 keys_zone=micro_cache:10m max_size=10g;
    server {
        location /dynamic {
            proxy_pass http://upstream;
            proxy_cache micro_cache;
            proxy_cache_valid 200 1s;
            proxy_cache_lock on;
            proxy_cache_lock_age 200ms;
            proxy_cache_use_stale updating;
        }
    }
}

內容解密：

此組態啟用了微快取功能，將動態內容快取1秒鐘。同時，啟用了快取鎖定機制，以防止在快取更新時向原始伺服器傳送多個請求。此外，當原始伺服器更新時，NGINX 可以使用過時的快取內容來回應請求，從而進一步提升效能。

快取控制

NGINX 提供了多種指令來控制快取行為，包括快取的有效性、快取鎖定、以及過期處理等。

快取控制範例

location / {
    proxy_pass http://upstream;
    proxy_cache my_cache;
    proxy_cache_valid 200 302 1h;
    proxy_cache_valid 301 1d;
    proxy_cache_valid any 1m;
    proxy_cache_min_uses 3;
    proxy_cache_revalidate on;
    proxy_cache_lock on;
    proxy_cache_use_stale error timeout http_500 http_502 http_503 http_504;
}

內容解密：

此組態對不同型別的 HTTP 回應設定了不同的快取有效期。同時，設定了快取最小使用次數為3次，並且啟用了快取重新驗證和快取鎖定。此外，當上游伺服器傳回錯誤或超時時，NGINX 可以使用過時的快取內容來回應請求。

隨著網路技術的不斷發展，快取技術也在不斷進化。未來，我們可以期待看到更多智慧型快取策略的出現，例如根據機器學習的快取最佳化技術。此外，隨著 HTTP/3 和 QUIC 協定的推廣，快取技術也需要相應地進行調整，以適應新的網路環境。

參考資源

• NGINX 官方檔案：https://nginx.org/en/docs/
• NGINX Plus 官方檔案：https://docs.nginx.com/nginx/admin-guide/

透過結合 NGINX 的強大功能和適當的快取策略，您可以為您的網站帶來顯著的效能提升和更好的使用者經驗。

高效能快取技術：NGINX 與 NGINX Plus 的應用實踐

快取基礎原理與效能最佳化

現代網站面臨的最大挑戰之一是提升頁面載入速度與系統回應效率。快取技術的引入能夠有效降低伺服器負載、減少頁面生成時間，進而提升整體使用者經驗。本文將探討 NGINX 與 NGINX Plus 的快取機制及其在實際應用中的組態方法。

重複性工作的解除安裝

快取的核心原理在於將重複性的工作從後端伺服器解除安裝。當第一位使用者請求特定內容時（圖示綠色圖示與綠線），NGINX 會將該請求轉發至後端伺服器（圖示灰色部分）。後端伺服器的回應不僅會傳回給使用者，同時 NGINX 會儲存該回應內容的副本。若後續有其他使用者（圖示灰色使用者）請求相同內容，NGINX 可直接從本地快取提供服務，無需再次請求後端伺服器。

這種機制大幅提升了系統效能，尤其是在處理大量重複請求時。舉例來說，筆者曾協助一個載入速度緩慢的網站進行效能調優。初步分析發現，其首頁生成時間超過一秒。進一步調查後發現，由於該頁面被標記為不可快取，每次請求都會動態生成。實際上，該頁面內容並不頻繁變更且無個人化需求。因此，將首頁快取時間設為 5 秒後，首次位元組到達時間（Time to First Byte）大幅縮短至幾毫秒，頁面載入速度明顯改善。

快取的基本運作原理

快取技術的核心在於減少後端伺服器的重複工作。當第一位使用者請求特定內容時，NGINX 會將請求轉發至後端伺服器，並將伺服器的回應內容儲存於本地快取中。當後續使用者請求相同內容時，NGINX 可直接從快取提供服務，無需再次請求後端伺服器。

  graph LR
    A[客戶端] -->|請求/index.html| B[NGINX 快取]
    B -->|快取命中| A
    B -->|快取未命中| C[後端伺服器]
    C -->|回應內容| B
    B -->|儲存快取| B

圖表翻譯： 此圖示展示了 NGINX 快取的基本運作流程。客戶端請求內容時，NGINX 首先檢查本地快取。若快取命中，則直接傳回內容；若未命中，則將請求轉發至後端伺服器，並將伺服器的回應內容儲存於快取中。

靜態檔案快取的實作

靜態檔案快取是 NGINX 的核心功能之一，主要用於快取圖片、CSS 和 JavaScript 等靜態檔案。實作靜態檔案快取可有效降低應用伺服器的負載，提升檔案檢索效率。

在 NGINX 網頁伺服器上實作靜態檔案快取時，主要涉及三個步驟：

1. 指定搜尋的根目錄
2. 處理請求
3. 最佳化回應速度

例如，以下組態片段啟用了 NGINX 的 sendfile 系統呼叫，透過避免將檔案複製到中間緩衝區來提升檔案傳輸效率：

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

這種組態能夠有效減少檔案傳輸的延遲，提升整體系統效能。

NGINX 快取組態實務

要在 NGINX 中啟用基本快取功能，主要需要兩個指令：proxy_cache_path 和 proxy_cache。

proxy_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m use_temp_path=off;
server {
    # ...
    location / {
        proxy_cache my_cache;
        proxy_pass http://my_upstream;
    }
}

上述組態中的 proxy_cache_path 指令設定了快取的路徑與相關引數：

• /path/to/cache/ 為本地磁碟上的快取目錄
• levels=1:2 建立了兩級目錄層次結構，以避免單一目錄下檔案數量過多影響存取效能
• keys_zone=my_cache:10m 設定了一個名為 my_cache 的分享記憶體區域，用於儲存快取鍵與相關中繼資料
• max_size=10g 限制了快取的最大空間使用量
• inactive=60m 設定了快取專案的閒置逾時時間

快取組態的關鍵引數解析

1. 快取路徑與目錄結構

   • /path/to/cache/ 指定了快取檔案在本地磁碟上的儲存位置
   • levels=1:2 建立兩級目錄結構，有效避免單一目錄下檔案數量過多導致的效能問題

2. 分享記憶體區域設定

   • keys_zone=my_cache:10m 建立了一個名為 my_cache 的分享記憶體區域
   • 該區域用於儲存快取鍵和相關中繼資料，如存取計數器和逾時計時器
   • 1MB 的記憶體空間大約可儲存 8,000 個快取鍵

3. 快取空間管理

   • max_size=10g 設定了快取的最大可用空間
   • 當快取空間使用達到上限時，NGINX 會根據快取清理策略移除最少使用的快取專案

4. 快取有效性管理

   • inactive=60m 指定了快取專案的最大閒置時間
   • 若某個快取專案在 60 分鐘內未被存取，則會被視為閒置並可能被清理

快取實作的最佳實踐

1. 快取層級結構設計
   採用多級快取機制可進一步提升系統效能。例如，可在 CDN 層級實施第一級快取，在 NGINX 層級實施第二級快取，形成多層次的快取架構。

2. 快取失效策略
   合理設定快取失效時間至關重要。對於頻繁更新的內容，應設定較短的快取時間；對於較少變更的內容，則可設定較長的快取時間。

3. 效能監控與調優
   透過 NGINX 的狀態模組，可即時監控快取命中率、快取使用量等關鍵指標。根據監控資料，可動態調整快取策略以最佳化系統效能。

4. 安全性考量
   在實施快取機制時，需確保敏感資訊不被快取。例如，對於包含使用者個人資訊的頁面，應設定為不可快取，以避免潛在的安全風險。

綜上所述，NGINX 提供了強大的快取功能，可有效提升網站效能並降低後端伺服器負載。透過合理的快取組態與最佳實踐，可進一步發揮 NGINX 在高效能網站架構中的作用。以下是一個完整的 NGINX 組態範例，展示瞭如何結合上述多項最佳實踐：

http {
    proxy_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m use_temp_path=off;
    
    server {
        listen 80;
        server_name example.com;
        
        location / {
            proxy_cache my_cache;
            proxy_pass http://backend_server;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_cache_valid 200 301 302 1h;
            proxy_cache_valid 404 1m;
            proxy_cache_revalidate on;
            add_header X-Cache-Status $upstream_cache_status;
        }
        
        location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
            proxy_pass http://backend_server;
            proxy_cache my_cache;
            proxy_cache_valid 200 1y;
            proxy_cache_valid 404 1m;
            expires max;
        }
    }
}

#### 內容解密：
此範例組態展示瞭如何在 NGINX 中實施多層次快取策略。對於一般動態內容，設定了 1 小時的快取有效期；對於靜態檔案（如圖片、CSS 和 JavaScript 檔案），則設定了長達 1 年的快取有效期。同時，啟用了快取重新驗證功能，以確保快取內容的新鮮度。

透過這種綜合性的快取組態，可有效提升網站的整體效能，同時確保內容的新鮮度與安全性。合理運用 NGINX 的快取功能，可為現代網站架構提供強有力的效能支援。

NGINX 快取組態與最佳化

NGINX 提供了一個高效能的快取機制，能夠顯著提升網站的效能和可靠性。本文將探討如何組態 NGINX 快取，以及如何對其進行最佳化。

基本快取組態

NGINX 的快取組態主要透過 proxy_cache_path 和 proxy_cache 兩個指令來完成。

proxy_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m use_temp_path=off;

server {
    location / {
        proxy_cache my_cache;
        proxy_pass http://my_upstream;
    }
}

內容解密：

• proxy_cache_path 指令定義了快取的路徑、層級結構、分享記憶體區網域名稱和大小、最大快取大小、非活躍資料的超時時間等。
  • /path/to/cache：快取資料存放的路徑。
  • levels=1:2：設定快取的目錄層級，第一層目錄名稱取 MD5 值最後一個字元，第二層取倒數第二和第三個字元。
  • keys_zone=my_cache:10m：定義了一個名為 my_cache 的分享記憶體區域，大小為 10MB，用於存放快取的鍵值。
  • max_size=10g：設定快取的最大大小為 10GB。
  • inactive=60m：設定非活躍資料在快取中保留的時間為 60 分鐘。
  • use_temp_path=off：關閉臨時路徑的使用，直接將檔案寫入快取目錄，避免不必要的檔案系統間資料複製。
• proxy_cache 指令啟用了對匹配 location 區塊 URL 的內容進行快取。

當來源伺服器不可用時提供快取內容

NGINX 可以組態為當來源伺服器不可用時，提供過期的快取內容。

location / {
    proxy_cache_use_stale error timeout http_500 http_502 http_503 http_504;
}

內容解密：

• proxy_cache_use_stale 指令允許 NGINX 在來源伺服器傳回錯誤或超時時，提供過期的快取內容。
  • error：在來源伺服器傳回錯誤時提供過期的快取內容。
  • timeout：在請求來源伺服器超時時提供過期的快取內容。
  • http_500, http_502, http_503, http_504：在來源伺服器傳回這些 HTTP 狀態碼時提供過期的快取內容。

快取最佳化

NGINX 提供了多個可選設定來最佳化快取效能。

proxy_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m use_temp_path=off;

server {
    location / {
        proxy_cache my_cache;
        proxy_cache_revalidate on;
        proxy_cache_min_uses 3;
        proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
        proxy_cache_lock on;
        proxy_pass http://my_upstream;
    }
}

內容解密：

• proxy_cache_revalidate 指令指示 NGINX 在重新整理來源伺服器的內容時使用條件式 GET 請求。
  • 當客戶端請求一個已快取但過期的專案時，NGINX 會在 GET 請求頭中包含 If-Modified-Since 欄位，以節省頻寬。
• proxy_cache_min_uses 指令設定了一個專案在被 NGINX 快取之前必須被客戶端請求的次數。
  • 預設值為 1，但可以設定為更大的值以確保只有最常存取的專案被加入快取。
• proxy_cache_use_stale 指令中的 updating 引數指示 NGINX 在更新快取內容時提供過期的內容。
  • 這可以避免多個客戶端請求同時轉發到來源伺服器。
• proxy_cache_lock 指令啟用後，當多個客戶端請求一個不在快取中的檔案時，只有第一個請求會被轉發到來源伺服器。
  • 其他請求會等待第一個請求完成並從快取中取得檔案。

跨多個硬碟分割快取

NGINX 允許將快取分散到多個硬碟上，以提高效能和可靠性。

proxy_cache_path /path/to/hdd1 levels=1:2 keys_zone=my_cache_hdd1:10m max_size=10g inactive=60m use_temp_path=off;
proxy_cache_path /path/to/hdd2 levels=1:2 keys_zone=my_cache_hdd2:10m max_size=10g inactive=60m use_temp_path=off;

split_clients $request_uri $my_cache {
    50% "my_cache_hdd1";
    50% "my_cache_hdd2";
}

server {
    location / {
        proxy_cache $my_cache;
        proxy_pass http://my_upstream;
    }
}

內容解密：

• 定義了兩個快取路徑，分別對應兩個不同的硬碟。
• 使用 split_clients 指令根據請求 URI 將客戶端請求平均分配到兩個快取中。
  • $request_uri 變數用於決定使用哪個快取。
  • 這樣可以確保相同的 URI 總是被快取在同一個快取中。