共用方式為

適用於 GraphQL 效能的網狀架構 API 最佳做法

Microsoft Fabric 的 GraphQL API 提供了一種高效查詢資料的強大方法，但效能最佳化是確保流暢且可擴展效能的關鍵。 無論您是處理複雜的查詢還是優化回應時間，下列最佳做法都可協助您從 GraphQL 實作中獲得最佳效能，並將 Fabric 中的 API 效率最大化。

誰需要效能優化

效能優化對以下方面至關重要：

  • 應用程式開發人員 構建高流量的應用程式，以查詢 Fabric 湖屋與倉庫
  • 資料工程師優化 Fabric 資料存取模式，以適用於大規模分析應用和 ETL 流程。
  • Fabric 工作區管理員 負責管理容量消耗並確保資源的有效利用
  • BI 開發者提升基於 Fabric 資料的客製化分析應用的回應時間
  • DevOps 團隊 在使用 Fabric API 的生產應用程式中排除延遲問題

當你的 GraphQL API 需要有效處理生產工作負載，或遇到效能問題時，請使用這些最佳實務。

區域劃分

跨區 API 呼叫是高延遲的常見原因。 為了達到最佳效能，請確保您的客戶應用程式、Fabric 租戶、容量與資料來源皆位於同一 Azure 區域。

檢查你的租戶區域

要找到你的 Fabric 租戶所在的區域：

  1. 以管理員帳號登入 Microsoft Fabric 入口網站
  2. 請選擇右上角的說明圖示（？）
  3. 在說明窗格底部，選擇「關於布料」
  4. 請注意租戶資料中顯示的區域

請查看你的容量區域

你的 GraphQL API 在特定容量內運作。 要找到容量區域：

  1. 開啟你為 GraphQL 提供 API 的工作空間

  2. 前往 Workspace 設定>授權資訊

  3. 在授權容量下查找該區域

    螢幕擷取畫面，顯示如何取得工作區的容量區域。

檢查你的資料來源區域

資料來源的位置也會影響效能：

  • Fabric 資料來源 （Lakehouse、Data Warehouse、SQL Database）：這些來源使用與工作區容量相同的區域
  • 外部資料來源 （Azure SQL 資料庫等）：請在 Azure 入口網站中查詢資源位置

最佳實務：在與 Fabric 容量及資料來源相同的區域部署用戶端應用程式，以降低網路延遲。

效能測試最佳實務

評估 API 效能時，請遵循以下指引以獲得可靠且一致的結果。

使用真實的測試工具

使用與你生產環境相近的工具進行測試：

  • 腳本或應用程式：使用 Python、Node.js或 .NET 腳本模擬實際客戶行為
  • HTTP 連線池：重用 HTTP 連線以降低延遲，這對跨區域情境尤其重要
  • 會話管理：在請求之間維持會話，以準確反映實際使用情況

範例資源：

收集有意義的指標

為了準確評估績效：

  1. 自動化測試：使用腳本或效能測試工具，在限定期間內持續執行測試
  2. 預熱 API：在測量效能前執行多個測試查詢（參見 預熱需求）
  3. 分析分布：使用百分位指標（P50、P95、P99）而非僅用平均值來理解延遲模式
  4. 負載測試：以現實的同時請求量來衡量效能
  5. 文件條件：記錄一天中的時間、容量使用率，以及測試期間任何同時進行的工作負載

常見效能問題

了解這些常見問題有助於你有效診斷並解決績效問題。

熱身要求

問題：第一個 API 請求比後續請求花費的時間明顯長得多。

原因如下：

  • API 初始化：當 API 環境閒置時，需在第一次呼叫時初始化，這會增加幾秒的延遲
  • 資料來源熱身：許多資料來源（尤其是 SQL Analytics 端點與資料倉儲）在閒置後存取時會進入暖機階段
  • 合併初始化：若 API 與資料來源皆閒置，初始化時間為複數

Solution:

  • 在測量效能前執行 2-3 次測試查詢
  • 對於生產應用程式，請實作健康檢查端點來保持 API 的溫度
  • 考慮使用排程查詢或監控工具，在營業時間內維持活躍狀態

區域錯位

問題：所有請求延遲都持續很高。

為什麼會這樣： 跨區域網路呼叫會增加顯著延遲，尤其當客戶端、API 和資料來源位於不同 Azure 區域時。

Solution:

  • 確認你的客戶應用程式、Fabric 容量和資料來源是否在同一區域
  • 若跨區域存取不可避免，請採用積極的快取策略。
  • 考慮部署區域性 API 副本以支援全球應用

資料來源效能

問題：即使 API 已經預熱並區域對齊，API 請求仍然很慢。

為什麼會這樣： GraphQL 的 API 作為對資料來源的查詢介面。 若底層資料來源存在效能問題——例如缺少索引、複雜查詢或資源限制——API 會繼承這些限制。

Solution:

  1. 直接測試：直接查詢資料來源（使用 SQL 或其他原生工具）以建立基準效能
  2. 優化資料來源：
  3. 適當容量：確保您的 Fabric 容量 SKU 提供足夠的運算資源。 請參閱 Microsoft Fabric 概念 以獲得選擇適當容量的指引。

查詢設計

問題：有些查詢表現良好，有些則較慢。

原因如下：

  • 過度抓取: 請求超過必要的欄位會增加處理時間
  • 深度巢狀：擁有多層巢狀關係的查詢需要多個解析器執行
  • 缺少篩選條件：若查詢未使用適當篩選條件，可能會回傳過多資料

Solution:

  • 請只索取你在 GraphQL 查詢中需要的欄位
  • 盡可能限制巢狀關係的深度
  • 在查詢中使用適當的篩選條件和頁碼
  • 適當時，考慮將複雜查詢拆解成多個較簡單的查詢

相關內容

  • Last updated on