次の方法で共有

GraphQL 用ファブリック API のパフォーマンスのベスト プラクティス

Microsoft Fabric の GraphQL 用 API は、データに効率的にクエリを実行する強力な方法を提供しますが、パフォーマンスの最適化は、スムーズでスケーラブルなパフォーマンスを確保するための鍵となります。 複雑なクエリを処理する場合でも、応答時間を最適化する場合でも、次のベスト プラクティスは、GraphQL 実装から最適なパフォーマンスを得て、Fabric で API の効率を最大化するのに役立ちます。

リージョン

リージョン間の呼び出しは、通常、待機時間が長くなる原因になる可能性があります。 最適なパフォーマンスを実現するには、クライアントが同じテナントと容量リージョンの API に接続することをお勧めします。

テナント リージョン

テナント リージョンは、次の手順で確認できます。

  1. 管理者アカウントを使用して Microsoft Fabric ポータルに移動し、右上隅にある [ヘルプ ? ] アイコンをクリックします。
  2. [ヘルプ] セクションの下部にある [ファブリックについて] リンクをクリックします。
  3. テナントに関する詳細 (リージョンを含む) が表示されます。

容量リージョン

  1. Microsoft Fabric ポータルに移動し、Fabric の GraphQL 用 API をホストするワークスペースを開きます。

  2. ワークスペースの設定から、[ライセンス情報] に移動します。

  3. 容量リージョンの情報は、[ ライセンス容量] にあります。

    ワークスペースの容量リージョンを取得する方法を示すスクリーンショット。

データ ソースリージョン

  1. データ ソースが Fabric プラットフォームでホストされている場合、ワークスペースの容量リージョンはデータ ソース リージョンになります。

  2. データ ソースが Azure SQL データベースなどの Fabric プラットフォームの外部にある場合は、Azure portal でリージョン情報を見つけることができます。

パフォーマンス テスト

API のパフォーマンスを評価する場合は、一貫性のある信頼性の高い結果を得るために、次のガイドラインに従うことをお勧めします。

クライアント側ツール

クローゼットの動作をアプリケーションにエミュレートするには、スクリプトまたはデモ Web アプリケーションを使用してテストを実行してパフォーマンスを測定することをお勧めします。 それに加えて、HTTP 接続プールを使用すると、特にリージョンをまたがるシナリオの待機時間を大幅に短縮できます。

この サンプル パフォーマンス テスト スクリプト は、作業の開始に役立ちます。

関連記事:

データの収集と評価

スクリプトまたはパフォーマンス テスト ツールを使用して、明確に定義された期間にわたって要求の実行を自動化することをお勧めします。 平均またはパーセンタイルベースの結果を分析すると、より正確で偏りのないパフォーマンス測定が保証されます。

一般的な問題

API の待機時間とパフォーマンスに影響する可能性がある一般的な問題の一覧を次に示します。

  • クライアントの地理的な場所は、テナントと容量のリージョンとは異なります。

    • アプリケーションに最適なパフォーマンスを実現する場合は、クライアントと API リソースを同じリージョンに置くと、目標の達成に役立ちます。

  • テストする前に、GraphQL の API に対して数回クエリを実行します。

    • GraphQL 用 API では、アイドル状態のときに容量 (CU) が使用されたり消費されたりすることはありません。 つまり、最初の呼び出し中に API 環境を内部的に初期化する必要があります。この呼び出しには数秒かかります。 GraphQL 用 API には、継続的な呼び出しの待機時間を減らすのに役立つ内部キャッシュ メカニズムが用意されていますが、初期呼び出しの待機時間の急増が発生する可能性があります。
    • API 自体以外では、特定のデータ ソースがウォームアップ フェーズを受けることがわかっています。そのため、初期要求の待機時間が長くなります。 API がアイドル状態のデータ ソースにもアクセスしていて、最初の実行時にも初期化する必要がある場合は、データ ソースと API の両方の初期化を待機する必要があるため、待機時間が長くなります。
    • 環境の初期化は 1 回だけ行われるため、後続の呼び出しは高速です。

  • データ ソースとファブリックの容量関連のセットアップ。

    • GraphQL 用 API は、データ ソースの上のラッパーと考えることができます。 データ ソース自体の複雑さの性質上、パフォーマンスの問題がある場合は、API の待機時間が長くなる可能性があります。 このような場合は、データ ソースのクエリを直接テストして、GraphQL 用 API とより効果的なパフォーマンス比較を行うことをお勧めします。

    • GraphQL 用 API にアクセスすると、選択した Fabric 容量 SKU によってパフォーマンスが制限されます。

      • Fabric 容量 SKU とそのコンピューティング能力に関するこの一般的なガイダンスを参照してください。 Microsoft Fabric の概念

API のパフォーマンスには、いくつかの要因が影響を与える可能性があります。 最適化には、データ ソースのセットアップ、適切なリージョンの選択、パフォーマンスの効果的な測定を理解することが重要です。

関連コンテンツ