内部ベンチマークでは、Durable Task Scheduler によって処理された作業項目は、Durable Functions アプリで最も一般的に使用されるバックエンドであるAzure Storage プロバイダーよりも>約
アクションとは、オーケストレーションの開始、アクティビティのスケジュール設定、タイマーの処理など、スケジューラによって処理される個別の操作です。 完全な定義と課金の詳細については、「アクションとは」を参照してください。
ベンチマーク結果
Durable Task Scheduler は、Azure Storage、MSSQL、Netherite プロバイダーなど、他のストレージ プロバイダーに対してベンチマークされました。 結果は、Durable Task Scheduler が他のオプションよりも優れたアクションスループットを提供し、これにより特定の期間に処理されるオーケストレーター、エンティティ、およびアクティビティタスクの数が増えることを示しています。
次のグラフは、Durable Task Scheduler と Azure Storage プロバイダーの 1 秒あたりに処理された作業項目を、さまざまなワーカー数にわたって示しています。 Azure Storage プロバイダーは、Durable Functions アプリの既定で最もよく使用されるバックエンドであるため、比較として選択されました。
次の表は、ベンチマークの数値スループット値をまとめたものです。
| コンフィギュレーション | Azure Storage (作業項目／秒) | 耐久性タスクスケジューラ (作業項目/秒) | 高速化 |
|---|---|---|---|
| EP2、1 作業者 | 約250 | 約 1,400 | ~5.6x |
| EP2、2 ワーカー | ~430 | ~2,750 | ~6.4x |
| EP2、4 ワーカー | ~830 | ~3,750 | 最大 4.5 倍 |
注
これらの結果は内部ベンチマークに基づくものであり、相対的なパフォーマンスの大まかな比較を提供するためのものです。 結果は、ワークロードの特性によって異なります。
ベンチマーク手法
バックエンド プロバイダーの相対的なスループットをテストするために、これらのベンチマークは、5 つのアクティビティ関数 (都市ごとに 1 つ) を順番に呼び出す標準オーケストレーター関数を使用して実行されました。 各アクティビティは単に "Hello, {cityName}!" 文字列値を返し、他の処理は行いません。
ベンチマークの目的は、複雑すぎずに各バックエンドのオーバーヘッドを測定することです。 この種類のシーケンシャル オーケストレーションは、Durable Functions を含む関数アプリでの共通性のために選択されました。
テストの詳細
テストは、次の条件で構成されます。
- このテストに使用される関数アプリは 、1 から 4 つの Elastic Premium EP2 インスタンスで実行されます。
- オーケストレーション コードは、.NET 8 の
.NET Isolated worker モデルを使用して C# で記述されました。 - すべてのストレージ プロバイダーで同じアプリが使用されました。唯一の変更はバックエンド ストレージ プロバイダーの構成でした。
- テストは、 5,000 個のオーケストレーションを同時に開始する HTTP トリガーを使用してトリガーされます。
テストが完了すると、完了したオーケストレーションの合計数を合計実行時間で割ることによってスループットが計算されます。 結果が一貫していることを確認するために、各ストレージ プロバイダー構成に対してテストが複数回実行されました。
結果に影響を与える要因
結果は次によって異なる場合があります。
- オーケストレーションとアクティビティの複雑さ
- 同時に実行されているオーケストレーションの数
- オーケストレーションとアクティビティの間で渡されるデータ ペイロードのサイズ
- 仮想マシンのサイズと SKU
- コンピューティングとスケジューラの間のネットワーク待機時間
注
これらのベンチマークは、Microsoftによって内部的に実行され、スタンドアロンのテスト ハーネスとしては使用できません。 これらは、ストレージ バックエンドを選択する際の相対的なパフォーマンスの一般的な感覚を提供することを目的としています。