共用方式為

針對 Azure Front Door 的一般效能問題進行疑難排解

  • 發行項

效能問題可能源自數個潛在區域：Azure Front Door 服務、來源、要求用戶端，或任何這些躍點之間的路徑。 此疑難排解指南可協助您識別資料路徑上的哪個躍點最有可能是問題的根源，以及如何解決問題。

檢查已知問題

開始之前，請檢查任何有關下列項目的已知問題：

  • Azure Front Door 平台。
  • 路徑中的網際網路服務提供者 (ISP)。
  • 要求用戶端連線和擷取資料的能力。

案例 1：調查來源

如果其中一個源伺服器很慢，則透過 Azure Front Door 對物件的第一個要求速度很慢。 此外，如果未在 Azure Front Door 存在點 (POP) 快取內容，則會將要求轉送至來源。 從來源服務會抵消 POP 鄰近性與本機傳遞給要求用戶端的優點，轉而依賴來源的效能。

案例 1：所需的環境資訊

  • Azure Front Door 端點名稱
    • 端點主機名稱
    • 端點自訂網域 (如果適用)
    • 原始主機名稱
  • 受影響檔案的完整 URL

案例 1：疑難排解步驟

  1. 檢查受影響要求的回應標頭。

    若要檢查回應標頭，請在 Bash 中使用下列 curl 範例。 您也可以選擇 F12 鍵來使用瀏覽器的開發人員工具。 選取 [網路] 索引標籤，選取要調查的相關檔案，然後選取 [標頭] 索引標籤。如果檔案遺失，請在開啟開發人員工具時重新載入頁面。

    初始回應應具有 x-cache 或 CONFIG_NOCACHE 值的標頭TCP_MISS。 Azure Front Door POP 會將具有此值的要求轉送至來源。 來源會將該相同路徑上的傳回流量傳送給要求用戶端。

    以下是顯示 TCP_MISS 的範例：

    $ curl -I https://www.contoso.com/styles.css
HTTP/2 200
date: Wed, 28 Aug 2024 17:02:09 GMT
content-type: text/css
content-length: 2837
last-modified: Thu, 09 May 2024 20:49:36 GMT
etag: "b15-6180b8e9bd897"
vary: Accept-Encoding
x-azure-ref: 20240828T170209Z-AA11BB22CC33DD44EE55FF66AA77BB88CC99DD00
x-fd-int-roxy-purgeid: 0
x-cache: TCP_MISS
accept-ranges: bytes

    以下是顯示 TCP_HIT 的範例：

    curl -I https://www.contoso.com/styles.css
HTTP/2 200
date: Wed, 28 Aug 2024 17:04:38 GMT
content-type: text/css
content-length: 2837
last-modified: Thu, 09 May 2024 20:49:36 GMT
etag: "b15-6180b8e9bd897"
vary: Accept-Encoding
x-azure-ref: 20240828T170438Z-BB22CC33DD44EE55FF66AA77BB88CC99DD00EE11
x-fd-int-roxy-purgeid: 0
x-cache: TCP_HIT
x-cache-info: L1_T2
accept-ranges: bytes

  2. 繼續向端點傳送要求，直到具有內含 TCP_HIT 值的 x-cache 標頭。

    如果您一開始看到 CONFIG_NOCACHE，則路由組態中不會啟用快取。 在這裡情況下，您將不會看到 TCP_HIT。

  3. 如果效能問題已解決，則問題在於來源速度，而不是 Azure Front Door 效能。 負責人必須解決 Azure Front Door 快取設定或來源問題，以提高效能。

    如果問題持續發生，來源可能是要求內容或 Azure Front Door 服務的用戶端。 移至案例 2 以找出來源。

案例 2：單一用戶端或位置 (例如，ISP) 速度緩慢

如果在要求用戶端與 Azure Front Door POP 之間有不正確的網路路由，單一用戶端或位置可能會變慢。 您應該排除任何不正確的路由，因為它會影響 POP 的距離，這會抵消 Azure Front Door POP 的鄰近性優勢。

如果您使用虛擬私人網路 (VPN) 或屬於分散的公司網路，則高延遲或低頻寬可能是 ISP 問題造成的。 公司網路可以透過中央遠端點執行所有流量。

案例 2：所需的環境資訊

  • Azure Front Door 端點名稱
    • 端點主機名稱
    • 端點自訂網域 (如果適用)
    • 原始主機名稱
  • 受影響檔案的完整 URL
  • 要求用戶端資訊
    • 要求用戶端 IP
    • 要求用戶端位置
    • 要求 Azure 環境的用戶端路徑 (通常使用 tracert、pathping 或類似工具標識)

案例 2：疑難排解步驟

  1. 若要檢查 POP 的路徑，請使用 pathping 或類似工具傳送 500 個封包來檢查網路路由。

    Pathping 最多有 250 個查詢。 若要測試至 500，請執行下列查詢兩次：

    pathping /q 250 <Full URL of Affected File>

  2. 確定流量是否採用會增加時間或前往較遠區域的路徑。

    根據地理位置尋找未採用合理路線的 IP、城市或區域代碼 (例如：歐洲的流量正在路由傳送到美國)，或有過多的躍點數目。

  3. 若要排除要求用戶端設定，請從同一區域中的不同要求用戶端進行測試。

  4. 如果您發現其他躍點或遠端區域，問題在於用戶端存取 Azure Front Door POP，而不是 Azure Front Door 服務本身。 連線能力或 VPN 提供者必須解決端點之間的躍點。

    如果您未找到其他躍點或遠端區域 和，且內容是由快取 (x-cache: TCP_HIT) 提供，則問題在於 Azure Front Door 服務。 您可能需要建立支援要求。 包含此疑難排解文章以及您採取步驟的參考。

注意

從來源 (x-cache: TCP_MISS) 提供內容時，請參閱本文前面的案例 1。

案例 3：網站載入速度緩慢

在某些情況下，單一檔案沒有問題，但整個 (Azure Front Door 代理) 網頁的效能並不符預期。 與 Azure Front Door 之外的網頁相比，網頁效能工具顯示的網站效能較差。

網頁通常由許多檔案組成。 只有當 Azure Front Door 提供網頁上每個檔案時，Azure Front Door 才會對網站有助益。 您必須將 Azure Front Door 設定為最大化優勢。

請考慮下列範例：

  • 來源：origin.contoso.com
  • Azure Front Door 自訂網域：contoso.com
  • 您嘗試載入的頁面：https://contoso.com

當載入頁面時，位於 「/」 目錄的初始檔案會呼叫其他檔案，以建置頁面。 這些檔案是影像、JavaScript、文字檔等等。 如果未透過 Azure Front Door 主機名稱 (contoso.com) 呼叫這些檔案，頁面就不會使用 Azure Front Door。 因此，如果網站要求的其中一個檔案是 http://www.images.fabrikam.com/businessimage.jpg，則使用 Azure Front Door 對檔案沒有幫助。 相反地，要求用戶端上的瀏覽器會直接從 images.fabrikam.com 伺服器要求檔案。

單一網站的多個不同來源檔案圖表以及該設定如何影響 Azure Front Door 效能。

案例 3：所需的環境資訊

  • Azure Front Door 端點名稱
    • 端點主機名稱
    • 端點自訂網域 (如果適用)
    • 原始主機名稱
    • 來源的地理位置
  • 受影響網頁的完整 URL
  • 測量效能的工具和計量

案例 3：疑難排解步驟

  1. 檢視顯示效能較慢的計量。

    重要

    Microsoft 無法辨別其未擁有的工具正在測量什麼。

  2. 在瀏覽器中開啟 Azure Front Door 網頁，然後選擇 F12 鍵來開啟開發人員工具。

    您可以使用瀏覽器中的開發人員工具來判斷所提供檔案的來源。 若要在開發人員工具中檢視 要求 URL，請選取 [網路] 索引標籤，選取您要調查的檔案，然後選取 [一般]。 如果檔案遺失，請在開啟開發人員工具時重新載入頁面。

  3. 記下檔案的來源或要求 URL。

  4. 找出哪些檔案使用 Azure Front Door 主機名稱，以及哪些檔案未使用。

    在前述範例中，裝載在 Azure Front Door 中的映像會是 https://www.contoso.com/productimage1.jpg。 未裝載在 Azure Front Door 中的映像會是 http://www.images.fabrikam.com/businessimage.jpg。

  5. 測試 Azure Front Door 所提供檔案的性能、其來源以及測試網頁 (如果適用)。

    如果來源或測試網頁是從更接近測試效能工具的地理區域提供的，則可能需要使用另一個區域中的工具或要求客戶端來檢查 Azure Front Door POP 的鄰近性優勢。

    重要

    從 Azure Front Door 主機名稱外部提供的任何檔案都無法從中受益。 您可能需要重新設計網頁才能如預期般工作。

    如果要快取檔案，請務必測試具有回應標頭 x-cache: TCP_HIT 的檔案。

  6. 根據收集的資料採取動作：

    • 如果收集的資料顯示是從 Azure Front Door 主機名稱以外的伺服器發出檔案，Azure Front Door 如預期般工作。

      緩慢載入的網站可能需要更改網頁設計。 如需最佳化網站以使用 Azure Front Door 的協助，請與您的網站設計小組或 Microsoft 解決方案提供者聯絡。

      注意

      根據網站設計的複雜度及其檔案呼叫指示，緩慢載入網站的問題可能需要時間來檢閱。

    • 如果收集的資料顯示，與來源或測試網站相比，Azure Front Door 的檔案載入效能更好，則 Azure Front Door 正在按預期般工作。 問題的來源可能是個別用戶端的要求。 在此情況下，請參閱本文前面的案例 1。

    • 如果收集的資料顯示 Azure Front Door 的效能沒有更好，您可能需要提出支援要求以進一步調查。 包含此疑難排解文章以及您採取步驟的參考。