Azure AI Search のパフォーマンス ベンチマーク
重要
これらのベンチマークは、古いインフラストラクチャで実行されるデプロイの "2024 年 4 月 3 日より前に" 作成された検索サービスに適用されます。 また、これらのベンチマークは、非ベクトル ワークロードにのみ適用されます。 新しい制限では、サービスとワークロードの更新が保留中です。
パフォーマンス ベンチマークは、同様の構成で潜在的なパフォーマンスを見積もる場合に役立ちます。 実際のパフォーマンスは、検索サービスのサイズや送信するクエリの種類など、さまざまな要因によって変わります。
ワークロードに必要な検索サービスのサイズを推定できるように、さまざまな検索サービスと構成のパフォーマンスを文書化するための、いくつかのベンチマークを実行しました。
さまざまなユース ケースに対応するために、次の 2 つの主要なシナリオでベンチマークを実行しました。
- eコマース検索 - このベンチマークは、eコマースの実際のシナリオをエミュレートしたもので、北欧の eコマース企業 CDON に基づいています。
- ドキュメント検索 - このシナリオは、Semantic Scholar のドキュメント全文に対するキーワード検索で構成されています。 これは、一般的なドキュメント検索ソリューションをエミュレートします。
これらのシナリオにはさまざまなユース ケースが反映されていますが、どのシナリオも異なるため、常に個々のワークロードのパフォーマンスをテストすることをお勧めします。 Microsoft は JMeter を使用したパフォーマンス テスト ソリューションを公開し、独自のサービスに対して同様のテストを実行できるようにしました。
テスト方法
Azure AI Search のパフォーマンスにベンチマークを設定するために、さまざまな階層と、レプリカやパーティションの組み合わせで 2 つの異なるシナリオに対してテストを実行しました。
このようなベンチマークを作成するために、次の方法が使用されました。
- テストは、180 秒間に
X
QPS (1 秒あたりのクエリ数) で開始されます。 これは通常、5 または 10 QPS でした。 - QPS はその後
X
ずつ増加し、さらに 180 秒間実行されました - 180 秒ごとに、平均待機時間が 1,000 ミリ秒を超えるか、またはクエリの成功率が 99% 未満に達するまで、テストが
X
QPS ずつ増加しました。
次のグラフは、テストのクエリの負荷の例をビジュアルで示しています。
各シナリオでは、キャッシュによってテストに過度のずれが生じないように、少なくとも 10,000 の一意のクエリを使用しました。
重要
これらのテストには、クエリ ワークロードのみが含まれます。 大量のインデックス作成操作が予想される場合は、そのことを見積もりとパフォーマンス テストに考慮してください。 インデックス作成をシミュレートするためのサンプル コードについては、このチュートリアルを参照してください。
定義
最大 QPS - 最大 QPS 数は、テストで達成された最大 QPS に基づいています。ここで、クエリの 99% はスロットリングがなく、平均待機時間が 1000 ms 未満で、正常に完了しています。
最大 QPS の割合 - 特定のテストに対して達成された最大 QPS の割合。 たとえば、特定のテストが最大 100 QPS に達した場合、最大 QPS の 20% は 20 QPS になります。
待機時間 - クエリに対するサーバーの待機時間。この数値には、ラウンド トリップ遅延 (RTT) は含まれません。 結果はミリ秒 (ms) 単位で示されます。
テストの免責事項
これらのベンチマークの実行に使用されたコードは、azure-search-performance-testing リポジトリで入手できます。 JMeter パフォーマンス テスト ソリューションでは、ベンチマークよりも少し低い QPS レベルが見られたことに注意してください。 違いは、テストのスタイルの違いが原因である場合があります。 これは、運用ワークロードに可能な限り近いパフォーマンス テストを行うことが重要であることを示しています。
重要
これらのベンチマークは、サービスの一定レベルのパフォーマンスを保証するものではありませんが、シナリオに応じて期待できるパフォーマンスを把握できます。
ご質問やご不明な点がある場合は、azuresearch_contact@microsoft.com にご連絡ください。
ベンチマーク 1: eコマース検索
これらのテストを実行するために、CDON の運用検索インデックスと、Web サイトから何千もの一意のクエリのスナップショットを使用しました。
シナリオの詳細
- ドキュメント数: 6,000,000
- インデックス サイズ: 20 GB
- インデックス スキーマ: 合計 250 のフィールド、25 の検索可能なフィールド、200 のファセット化またはフィルターが可能なフィールドを含む幅広いインデックス
- クエリの種類: ファセット、フィルター、順序付け、スコアリング プロファイルを含むフル テキスト検索クエリ
S1 のパフォーマンス
秒間クエリ
次のグラフは、サービスが長時間にわたって処理できる最高のクエリ負荷を、1 秒あたりのクエリ数 (QPS) で示しています。
クエリの待機時間
クエリの待ち時間は、サービスの負荷によって異なり、高い負荷の下にあるサービスでは、クエリの平均待ち時間が長くなります。 次の表は、3 つの異なる使用レベルのクエリ待機時間の 25、50、75、90、95、99 番目のパーセンタイルを示しています。
最大 QPS の割合 | 平均待機時間 | 25% | 75% | 90% | 95% | 99% |
---|---|---|---|---|---|---|
20% | 104 ms | 35 ミリ秒 | 115 ms | 177 ms | 257 ms | 738 ms |
50% | 140 ms | 47 ms | 144 ms | 241 ms | 400 ミリ秒 | 1175 ms |
80% | 239 ms | 77 ms | 248 ms | 466 ms | 763 ms | 1752 ms |
S2 のパフォーマンス
秒間クエリ
次のグラフは、サービスが長時間にわたって処理できる最高のクエリ負荷を、1 秒あたりのクエリ数 (QPS) で示しています。
クエリの待機時間
クエリの待ち時間は、サービスの負荷によって異なり、高い負荷の下にあるサービスでは、クエリの平均待ち時間が長くなります。 次の表は、3 つの異なる使用レベルのクエリ待機時間の 25、50、75、90、95、99 番目のパーセンタイルを示しています。
最大 QPS の割合 | 平均待機時間 | 25% | 75% | 90% | 95% | 99% |
---|---|---|---|---|---|---|
20% | 56 ミリ秒 | 21 ミリ秒 | 68 ms | 106 ミリ秒 | 132 ms | 210 ms |
50% | 71 ms | 26 ms | 83 ms | 132 ms | 177 ms | 329 ms |
80% | 140 ms | 47 ms | 153 ミリ秒 | 293 ms | 452 ms | 924 ms |
S3 のパフォーマンス
秒間クエリ
次のグラフは、サービスが長時間にわたって処理できる最高のクエリ負荷を、1 秒あたりのクエリ数 (QPS) で示しています。
この例では、2 番目のパーティションを追加すると最大の QPS が大幅に増加しますが、3 番目のパーティションを追加すると、わずかな変化しかありません。 2 つのパーティションしかない S3 のアクティブなメモリにすべてのデータが既に取り込まれているため、少ししか改善されない場合があります。
クエリの待機時間
クエリの待ち時間は、サービスの負荷によって異なり、高い負荷の下にあるサービスでは、クエリの平均待ち時間が長くなります。 次の表は、3 つの異なる使用レベルのクエリ待機時間の 25、50、75、90、95、99 番目のパーセンタイルを示しています。
最大 QPS の割合 | 平均待機時間 | 25% | 75% | 90% | 95% | 99% |
---|---|---|---|---|---|---|
20% | 50 ミリ秒 | 20 ミリ秒 | 64 ms | 83 ms | 98 ms | 160 ミリ秒 |
50% | 62 ms | 24 ms | 80 ミリ秒 | 107 ms | 130 ミリ秒 | 253 ms |
80% | 115 ms | 38 ms | 121 ms | 218 ms | 352 ms | 828 ms |
ベンチマーク 2: ドキュメント検索
シナリオの詳細
- ドキュメント数: 750 万
- インデックス サイズ: 22 GB
- インデックス スキーマ: 23 のフィールド、8 つ検索可能、10 のフィルターまたはファセット化が可能
- クエリの種類: ファセットを使用したキーワード検索と強調表示
S1 のパフォーマンス
秒間クエリ
次のグラフは、サービスが長時間にわたって処理できる最高のクエリ負荷を、1 秒あたりのクエリ数 (QPS) で示しています。
クエリの待機時間
クエリの待ち時間は、サービスの負荷によって異なり、高い負荷の下にあるサービスでは、クエリの平均待ち時間が長くなります。 次の表は、3 つの異なる使用レベルのクエリ待機時間の 25、50、75、90、95、99 番目のパーセンタイルを示しています。
最大 QPS の割合 | 平均待機時間 | 25% | 75% | 90% | 95% | 99% |
---|---|---|---|---|---|---|
20% | 67 ms | 44 ms | 77 ms | 103 ms | 126 ms | 216 ms |
50% | 93 ms | 59 ミリ秒 | 110 ms | 150 ms | 184 ms | 304 ms |
80% | 150 ms | 96 ms | 184 ms | 248 ms | 297 ms | 424 ms |
S2 のパフォーマンス
秒間クエリ
次のグラフは、サービスが長時間にわたって処理できる最高のクエリ負荷を、1 秒あたりのクエリ数 (QPS) で示しています。
クエリの待機時間
クエリの待ち時間は、サービスの負荷によって異なり、高い負荷の下にあるサービスでは、クエリの平均待ち時間が長くなります。 次の表は、3 つの異なる使用レベルのクエリ待機時間の 25、50、75、90、95、99 番目のパーセンタイルを示しています。
最大 QPS の割合 | 平均待機時間 | 25% | 75% | 90% | 95% | 99% |
---|---|---|---|---|---|---|
20% | 45 ms | 31 ms | 55 ミリ秒 | 73 ミリ秒 | 84 ms | 109 ms |
50% | 63 ms | 39 ms | 81 ms | 106 ミリ秒 | 123 ms | 163 ms |
80% | 115 ms | 73 ミリ秒 | 145 ms | 191 ms | 224 ms | 291 ms |
S3 のパフォーマンス
秒間クエリ
次のグラフは、サービスが長時間にわたって処理できる最高のクエリ負荷を、1 秒あたりのクエリ数 (QPS) で示しています。
クエリの待機時間
クエリの待ち時間は、サービスの負荷によって異なり、高い負荷の下にあるサービスでは、クエリの平均待ち時間が長くなります。 次の表は、3 つの異なる使用レベルのクエリ待機時間の 25、50、75、90、95、99 番目のパーセンタイルを示しています。
最大 QPS の割合 | 平均待機時間 | 25% | 75% | 90% | 95% | 99% |
---|---|---|---|---|---|---|
20% | 43 ms | 29 ms | 53 ms | 74 ミリ秒 | 86 ms | 111 ms |
50% | 65 ms | 37 ms | 85 ms | 111 ms | 128 ms | 164 ms |
80% | 126 ms | 83 ms | 162 ms | 205 ms | 233 ms | 281 ms |
重要なポイント
これらのベンチマークを通じて、Azure AI Search が提供するパフォーマンスを把握できます。 また、異なる階層のサービスの違いを確認することもできます。
これらのベンチマークでは、次のようないくつかの重要なポイントがあります。
- 通常、S2 は S1 の少なくとも 4 倍のクエリ ボリュームを処理できます
- 通常、S2 では、同等のクエリ ボリュームで S1 よりも待ち時間が短くなります
- レプリカを追加すると、サービスが処理できる QPS は通常、線形にスケーリングできます (たとえば、あるレプリカが 10 QPS を処理できる場合、5 つのレプリカでは通常 50 QPS を処理できます)
- サービスの負荷が高いほど、平均待ち時間が長くなります
また、シナリオによってパフォーマンスが大きく異なることもわかります。 期待したパフォーマンスが得られない場合は、パフォーマンス向上のヒントに関する記事をご確認ください。
次のステップ
パフォーマンスのベンチマークについて見てきたので、パフォーマンスに影響を与える Azure AI Search のパフォーマンスと重要な要因の分析方法について詳しく知ることができます。