Esrallyのスコアの見方について

[r-takebayashi (竹林諒)]

某コンテナ製品上で稼働するElasticsearchと物理環境で稼働するElasticsearchの性能を比較するためにesrallyを利用しました。

trackはgeonamesとpmcを使いました。
性能測定結果はバラつきはあるものの概ね同等程度であり、物理環境でのElasticsearchの方がやや優れた結果になりました。

しかし、geonamesのdefaultのlatencyは最大で650倍程度の差が出ており、かなり懸念のある結果となりました。ただ、defaultというOperationそもそも何を示しているか分かりません。

これはどのようなアクションをイメージしているのでしょうか？
また、node-statsというものもいまいちよく分からないのですが、それぞれのOperatiionが示されている情報等はございますでしょうか？

[johtani (Jun Ohtani)]

こちらは読まれましたでしょうか？
https://esrally.readthedocs.io/en/stable/

[r-takebayashi (竹林諒)]

ご返信ありがとうございます。
はい。事前に参照し、再度参照してみましたがoperationのdefaultが何を示しているのかが、理解できませんでした。

[st1t (Shota Ito)]

ドキュメントはRallyの概要までしか書いてないと思いますので、
合わせてgithubで公開されているrally-tracksの各trackのtrack.json辺りを読んでみるのが良いかと思います。

• trackの構成要素
• rally-tracks

以下個人的な解釈としてgeonamesについて書いておきます。
※解釈が間違っていたらご指摘ください。

geonamesのtrack.jsonについて見てみると、

• challenges

        {
          "operation": "default",
          "clients": 1,
          "warmup-iterations": 500,
          "iterations": 1000,
          "target-throughput": 50
        },

• operations

	{
      "name": "default",
      "operation-type": "search",
      "body": {
        "query": {
          "match_all": {}
        }
      }
    },

と記載されているので、
デフォルトでは

• 1クライアントでタスクを実行
• ウォームアップとして500回実行
• 1000回実行して実測値を計測
• 50リクエスト発行
• 上記設定でsearch APIでmatch_allを実行

というベンチマークになると思います。

手間はかかりますが、なぜ時間がかかるのか、どういう検索をしているか把握するために
trackで使われるindexやtemplateをダウンロードしてデータ構造を確認してみるのが良いと思います。

いずれにしても本当に意義のあるベンチマークをきちんと取るのは結構難しいです。
概要程度に留めないで本気でベンチマークをされるのでしたら
最終的にはRallyを使って自分の環境に合ったデータセットやtrack等を自作するところまでやらないと駄目かと思います。
また、負荷のかかり方をきちんと理解するならデータセットやElasticsearchそのものの振舞いはもちろん、
その振舞いに応じてKernelや物理レイヤがどういう挙動になるのかを突き詰めて考える必要があります。
目的とベンチマークの結果予想と結果とどう乖離していたか等を気にしながらやるのはもはや職人芸ですね。。。
※私はほどほどのところで留めてしまっています。。。