メモ
コミュニティの関心グループが Yammer から Microsoft Viva Engage に移行されました。 Viva Engage コミュニティに参加し、最新のディスカッションに参加するには、「 Finance and Operations Viva Engage Community へのアクセスを要求する 」フォームに入力し、参加するコミュニティを選択します。
この記事では、サービス保護アプリケーション プログラミング インターフェイス (API) の制限に対するスロットル応答の管理と、API スループットの最大限化に役立つ戦略について説明します。
最短の期間で最も多くのデータを移動するためにスループットに優先順位を付ける必要があるアプリケーションがある場合は、これらの戦略を適用します。
要求を再試行するタイミングをサーバーに指示させる
一度に送信する要求の数を計算しようとしないでください。 環境ごとに異なる場合があります。 限界に達するまで、リクエストを送信するレートを徐々に上げていきます。 次に、サービス保護 API 制限の再試行間隔の値に依存して、送信するタイミングを指示します。 この値は、合計スループットを可能な限り高いレベルに維持するのに役立ちます。
詳細については、再試行操作 を参照してください。
複数のスレッドの使用
個々の操作が比較的速い場合、アプリケーションは同時実行スレッドの数の上限を使用して、パフォーマンスを大幅に向上させることができます。 処理するデータの性質によっては、最適なスループットを実現するためにスレッドの数を調整する必要がある場合があります。
複数のサービス プリンシパル間でのワークロードの配分
ユーザーベースのサービス保護 API の制限は、ユーザーごとに実装されます。 統合で 1 つのサービス プリンシパルを使用して大規模な一括データ操作を実行する場合、または 1 つのサービス プリンシパルを使用してすべてのユーザー要求をサーバーに送信する対話型クライアント アプリケーションの場合は、サービス保護 API の制限にかなり早く到達できます。 複数のサービス プリンシパル間でワークロードを小さなバッチで分配することで、この問題を防ぐのに役立ちます。
大きなバッチを避ける
バッチ処理とは、単一の要求に対して複数の操作を送信するプロセスを指します。 ほとんどのシナリオは、単一の要求を送信し、高度な並列処理を使用する場合に最も高速です。 バッチ サイズがパフォーマンスの向上に役立つ可能性があると思われる場合は、小さなバッチ サイズから開始し、操作を再試行する必要があることを示すサービス保護 API 制限エラーの受信を開始するまでコンカレンシーを増やします。 財務と運用アプリでは、バッチ サイズは 5,000 操作に限定されます。
財務と運用アプリのサービス エンドポイントを持つバッチ要求の詳細については、バッチ要求 を参照してください。
アフィニティ cookie の削除
Azure のサービスに接続すると、応答に Cookie が含まれます。 後続のすべての要求は、容量管理によって別のサーバーに送信されない限り、同じサーバーに移動しようとします。 Cookie を削除すると、各要求を任意の対象サーバーにルーティングできます。 サーバーごとに制限が適用されるため、スループットが向上します。 この方法では、使用可能な場合は、より多くのサーバーを使用できます。
メモ
この戦略は、スループットを最適化する必要があるアプリケーションにのみ使用します。 対話型クライアント アプリケーションでは、別の方法で再作成する必要があるキャッシュされたデータを再利用できるため、アフィニティ Cookie のメリットがあります。 データを再作成する必要がある場合、パフォーマンスが低下します。
次のコードでは、Web サービスを使用して HttpClient を初期化するときに cookie を無効にする方法を示します。 カスタム HttpMessageHandler を使用して認証を管理していることを前提としています。
HttpMessageHandler messageHandler = new OAuthMessageHandler(
config,
new HttpClientHandler() { UseCookies = false }
);
HttpClient httpClient = new HttpClient(messageHandler)
接続の最適化
接続を最適化すると、スループットが向上する可能性があります。 サポートされている .NET サンプル コードでは、次の設定を使用します。
//Change max connections from .NET to a remote service default: 2
System.Net.ServicePointManager.DefaultConnectionLimit = 65000;
//Bump up the min threads reserved for this app to ramp connections faster - minWorkerThreads defaults to 4, minIOCP defaults to 4
System.Threading.ThreadPool.SetMinThreads(100, 100);
//Turn off the Expect 100 to continue message - 'true' will cause the caller to wait until it round-trip confirms a connection to the server
System.Net.ServicePointManager.Expect100Continue = false;
//Can decrease overall transmission overhead but can cause delay in data packet arrival
System.Net.ServicePointManager.UseNagleAlgorithm = false;
詳細については、接続の管理 を参照してください。