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

2025-05-27

Microsoft Fabric 的 GraphQL API 提供有效率地查詢數據的強大方式，但效能優化是確保順暢且可調整效能的關鍵。無論您是處理複雜的查詢或優化回應時間，下列最佳做法可協助您在 GraphQL 實作中獲得最佳效能，並在 Fabric 中將 API 效率最大化。

地區

跨區域呼叫通常是高延遲的原因。為了達到最佳效能，建議客戶連線到相同租用者和容量區域的 API。

租用戶區域

您可以使用下列步驟來尋找租用戶區域：

移至具有系統管理員帳戶的 Microsoft Fabric 入口網站，然後按下右上角的 [說明 ? ] 圖示。
在說明區段底部，點擊 關於 Fabric 連結。
您的租戶詳細資料，包括地區，將會顯示。

容量區域

移至 Microsoft Fabric 入口網站，開啟裝載您 Fabric 的 GraphQL API 的工作區。
從 [工作區設定] 移至 [ 授權資訊]。
您可以在 [授權容量] 底下找到您的容量區域資訊。

數據源區域

如果您的數據源裝載在 Fabric 平臺中，工作區的容量區域會是數據源區域。
如果您的數據源位於 Fabric 平臺之外，例如 Azure SQL 資料庫，您應該能夠在 Azure 入口網站中找到區域資訊。

效能測試

對於評估其 API 效能的客戶，我們建議遵循下列指導方針，以確保一致且可靠的結果。

用戶端工具

若要模擬應用程式的壁櫥行為，建議您使用腳本或示範 Web 應用程式來執行測試以測量效能。除此之外，使用 HTTP 連線共用可以大幅降低跨區域案例的延遲。

您可以使用此範例效能測試腳本，協助您開始使用。

數據收集和評估

建議您使用文稿或效能測試工具，在定義完善的時間週期內自動執行要求。分析以平均或百分位數為基礎的結果有助於確保更精確且不偏不倚的效能測量。

常見問題

以下是可能會影響 API 延遲和效能的常見問題清單。

您的用戶端地理位置與您的租戶和容量區不同。
- 如果您想要達到應用程式的最佳效能，讓相同區域中的用戶端和 API 資源有助於達成目標。
在測試之前，先查詢 GraphQL 的 API 數次：
- GraphQL 的 API 在閒置時不會使用或消耗容量單位（CUs）。這表示在第一次呼叫期間，必須在內部初始化 API 環境，這需要幾秒鐘的時間。適用於 GraphQL 的 API 有內部快取機制，可協助減少連續呼叫的延遲，不過您可能會面臨初始呼叫的延遲尖峰。
- 除了 API 本身之外，某些數據源已知會經歷熱身階段，這會導致初始要求的延遲較高。如果 API 正在存取也閒置的數據源，而且在初次執行期間也需要初始化，延遲會更高，因為它需要等待數據源和 API 的初始化。
- 後續呼叫速度較快，因為環境初始化只會發生一次。
資料來源與Fabric資源相關設定。
- 您可以將適用於 GraphQL 的 API 視為數據源頂端的包裝函式。如果您的數據源本身因為其複雜性而發生效能問題，則預期 API 延遲可能會很高。發生這類情況時，建議您直接測試查詢您的資料來源，以更有效率地比較與 GraphQL API 的效能。
  - 遵循本指南，瞭解如何為業務需求選擇適當的數據存放區：網狀架構決策指南 – 選擇數據存放區
- 存取 GraphQL 的 API 時，效能將會由您選取的網狀架構容量 SKU 所系結。
  - 請參閱網狀架構容量 SKU 及其計算能力的相關一般指導方針： Microsoft網狀架構概念

有數個因素可能會影響 API 效能。了解數據源設定、選取正確的區域，並有效地測量效能對於優化至關重要。

共用方式為