概觀

使用 CloudFront 增加快取命中率 (CHR) 可提高 Web 應用程式的效能，並降低其來源的負載。CHR 是從 CloudFront 快取提供的 HTTP 請求與請求總數的比率。從 CloudFront 快取提供的請求的優點在於減少延遲 (例如，到最後一個位元組的時間)，使 CHR 成為來源卸載和應用程式效能的良好指標。您可以使用快取命中率 CloudWatch 指標來監控 CloudFront 分發的 CHR。若要增加 CHR，您可以將 CloudFront 中的快取組態最佳化、啟用 Origin Shield，並將應用程式行為最佳化。

使用 Amazon CloudFront 建立低延遲網站

增加快取存留時間 (TTL)

您可以使用來源傳送的 Cache-Control 標頭，控制物件在 CloudFront 中快取的時間長度，此時間受到「快取政策」中設定的存留時間設定限制。增加 TTL 會對 CHR 產生正面影響，因此建議：

  • 在來源上設定 Cache-Control 標頭，妥善地控制 CloudFront 中的 TTL，以及利用瀏覽器快取。
  • 將靜態資產快取為不可改變的物件 (例如，Cache-Control: max-age=31536000, immutable)，並對其 URL 路徑進行版本控制 (例如 /static/app.1be87a.js)。
  • 在您的物件上實作 ETAG，以便從傳送到來源的條件式 HTTP 請求中受益。
  • 為更動態的內容 (例如 HTML) 取得適當的平衡，例如在快取 (高 TTL) 和應用程式容忍過時內容程度 (低 TTL) 之間。

將快取金鑰設定最佳化

使用快取政策的快取金鑰設定可指定 CloudFront 是否要將快取物件重複用於 HTTP 請求。最佳化的快取金鑰設定會在唯一快取金鑰與唯一物件之間產生 1 對 1 的關係。請考慮一個 Web 應用程式，無論附加什麼查詢參數 (例如 /about.html?utm_medium=social)，該應用程式都可以提供相同的 /about.html。如果快取金鑰設定為包含 utm_medium 查詢參數，CloudFront 將會使用兩個不同的快取金鑰，快取不同的 URL (例如 /about.html?utm_medium=social 和 /about.html?utm_medium=email)。這會導致兩個快取未命中來源，即使兩個請求都是針對來源上完全相同的檔案也是如此，這不是最佳狀態。

最佳化快取金鑰設定的第一個最佳實務是僅包含在影響來源回應的快取金鑰請求屬性中。為此，建議您：

  • 針對需要不同快取金鑰設定的物件，設定個別的快取行為。
  • 如果查詢參數、標頭或 Cookie 會改變來源的回應，則只包含實際改變的查詢參數、標頭或 Cookie (例如，是 cookie user_id 而不是所有 Cookie)。
  • 在 CloudFront 中使用回應標頭政策管理 CORS，而不是將 CORS 標頭 (例如： Origin、Access-Control-Request-Method、Access-Control-Request-Headers) 新增到快取金鑰，並在來源層級管理 CORS。
  • 使用已簽署的 URL、CloudFront Functions 或 Lambda@Edge，將存取控制卸載至 CloudFront，而不是將授權標頭新增至快取金鑰，並在來源層級進行管理。
  • 使用 CloudFront 中的來源請求政策，將 HTTP 屬性轉送到來源，而不是將其新增到快取金鑰中。

第二個最佳實務是在將請求屬性新增到快取金鑰之前將其標準化，以減少其可能值的基數，每個值都會產生唯一的快取金鑰。為此，建議您：

  • 使用時，以相同的順序和相同大小寫傳送查詢參數
  • 使用 CloudFront 產生的標頭 (例如 CloudFront-IS-Mobile-Viewer) 來識別裝置類型，而不是將 User-agent 標頭新增至快取金鑰。
  • 使用 CloudFront Functions 套用進階標準化，例如：重新排序以及將查詢參數變成小寫；根據 Cookie 是否存在提供不同版本的網頁，而不是將 Cookie 新增到快取金鑰中；在可以針對一組國家/地區傳送相同回應時，減少因國家/地區而異的回應變異；當需要壓縮時，進一步減少 Accept-Encoding 的基數，或使用多個 CloudFront 裝置偵測標頭時，進一步減少其基數。

啟用 Origin Shield

根據預設，CloudFront 會使用兩個高層級快取層來減少快取未命中來源的次數：一層位於 PoP 層級，另一層則位於區域邊緣快取 (REC) 層級。CloudFront PoP 名義上與全球 10 多個 REC 之一相關聯。當請求導致 PoP 層級的快取未命中時，CloudFront 會檢查關聯 REC 的快取以履行請求，只有在該 REC 中未快取該請求時，CloudFront 才會將請求轉送到來源。REC 彼此隔離以維持高可用性，因此不會共用其快取。因此，從世界各地的不同位置請求熱門物件時，CloudFront 將從多個 REC 向來源傳送相同物件的多個請求。

若要減少轉送到來源的請求數量，您可以在 CloudFront 中啟用 Origin Shield，這是 REC 與您的來源之間的第三個高層級快取層。REC 會先嘗試從 Origin Shield 快取履行請求，而不是直接從來源請求物件。

將應用程式行為最佳化

考慮可以正面影響快取命中率的應用程式層級變更。範例包括：

  • 減少應用程式所提供的基數物件。當您的應用程式產生相同資產的多個轉譯 (例如，適合不同螢幕的不同大小影像)，請考慮限制寬度和高度的可能值數目。
  • 利用瀏覽器快取。這可以使用來源傳送的 Cache-Control 標頭完成。您可以透過在 Cache-Control 標頭中將 max-age 與 s-maxage 指示詞一起使用，或將 Cache-Control 標頭用於瀏覽器並使用快取政策控制 CloudFront TTL，來區分 CloudFront 與瀏覽器之間的 TTL。
  • 在用戶端中使用位元組範圍請求僅會下載所需的內容。

資源

本頁對您是否有幫助？

 意見回饋