SolrCloudモードでのSolrのパフォーマンスは悪い？
コピーリンク
(The bot translated the original post https://lists.apache.org/thread/mb44s7ys6cgyqb0jxybxgcpj6s89hgyq into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)
こんにちは皆さん、
私たちはスタンドアロンのSolrインスタンスからSolrクラスタに移行したいと考えています。私たちのコレクションにはそれほど多くのドキュメント（約80,000件）はなく、スタンドアロンのSolrインスタンスのパフォーマンスには非常に満足しています。k6ツールでいくつかテストを行ったところ、驚きました。
Solrスタンドアロン（Solr 9.6.1）：
http_req_duration..............: 平均=1.81ms 最小=1ms 中央値=1.6ms 最大=238.55ms p(90)=2.27ms p(95)=2.69ms
http_reqs......................: 31108 1032.228932/s
Solrクラスタ（Solr 9.7.0）：
http_req_duration..............: 平均=47.98ms 最小=7.93ms 中央値=48.15ms 最大=85.51ms p(90)=51.95ms p(95)=53.09ms
http_reqs......................: 1414 41.417403/s
両方のセットアップには以下があります：
- 同じドキュメントを持つコレクション（約80,000件）
- 同じIDPで設定されたJWT認証
- 2GBメモリ（最大ヒープ）
- 最大ファイルディスクリプタ1048576
- オペレーティングシステム（Debian Linux 11.5）
Solrクラスタは3ノードで構成されています。使用されるコレクションは1シャード3レプリカで定義されています。各Solrノードのシステムには、1つのZookeeperノードもあります。
なぜSolrCloudモードでパフォーマンスがこんなに悪いのか、その原因とパフォーマンスを改善する方法、またはどこを見直すべきかを説明していただける方はいますか？
よろしくお願いします。
Mihael
こんにちは、
まず、このパフォーマンス（48ms）が必ずしも悪いわけではありません。テストを実行する際は、常に同じ状態から開始し、新しく起動したサーバーを使用し、同じテストスイートを実行して、できれば10分以上の時間をかけてテストを行うようにしてください。さもないと、さまざまなキャッシュが影響を与える可能性があります。
1シャードのコレクションの場合、SolrCloudにはほとんどオーバーヘッドはなく、クエリを受け取ったノードでローカルインデックスに素早く委任されます。
ディスク上のインデックスのサイズとサーバーに搭載されている物理RAMの量を教えてもらえますか？ また、レプリカのいずれかにクエリを送信しているのか、負荷分散を試みているのかがわかりません。
まず1ノードのSolrCloudクラスターをベンチマークして、すべてを簡素化することを考慮してもよいでしょう。
Jan
こんにちは、Matthias、
テストはk6（k6.io）を使用して、ターゲットサーバーと同じLAN内にあるサーバーから実施しました。単一および複数の仮想ユーザーでテストを行いましたが、結果はすべて同じでした。Solrクラスターの設定からの平均応答時間は約50msでした。
リクエストは次のようになります： https://server/solr-cluster/mdm/select?q=clazz%3Axyz%20AND%20businessId%3A320987
businessIdは、10000件の既存のIDからランダムに選ばれます。したがって、常に同じIDがクエリされるわけではありません。
返されるJSON内の各ドキュメントには、約12の属性があり、合計で約400文字です。
これが分析に役立つことを願っています。
よろしくお願いします。
Mihael
こんにちは、Matthias、SolrCloudには各インスタンスにシャードが1つだけですか、それとも複数ですか？
Vincenzo D'Amore
コレクションは1つのシャードと3つのレプリカで作成されています。したがって、各ノードにはコレクション全体があり、リクエストに応答できます。
よろしくお願いします。
Mihael
QTimeの値は3msから18msの間です。そして、クライアントがレスポンスを受け取るまでの時間は約30ms長いです。これは、ネットワークがリクエストに約30msの遅延を追加していることを意味しますか？
よろしくお願いします。
Mihael
まだ調査中ですが、ローカルシャードを選択するパラメータを追加して試しましたか？
たしか、preferLocalShards のようなパラメータがあったと記憶しています（確か非推奨になったはずですが）。
--
Vincenzo D'Amore
こんにちは、Vincenzo。
情報ありがとうございます。shards というクエリパラメータがあり、これを使えばシャードとレプリカを選択できるようです。
よろしくお願いします。
Mihael
両方のケースで同じスキーマを使用していますか？
"businessId" は数値フィールドですか、それとも文字列ですか？
こんにちは Tomás、
両方のケースで同じスキーマと同じデータを使用しています。
businessId は数値フィールドです。
よろしくお願いします。
Mihael
これが変更されていないことを考えると、パフォーマンス低下の原因とは考えにくいですが、SOLR-11078[1] の問題に直面している可能性もあります。
もしスキーマが比較対象の間で変わっていないのであれば、問題は SOLR-11078 ではありません。
以前、QTime について質問されていましたね。QTime は、Solr が返すべきドキュメントを特定し、すべての検索コンポーネント（例: ファセット、ハイライティング）が完了した時点で終了します。その後、Solr はインデックスから必要な値（"fl" パラメータで指定されたフィールド）を取得し、選択したフォーマットでシリアライズしてネットワーク経由で返す処理を行います。
トピックへ返信するには、ログインが必要です。