DroongaとGroongaのベンチマークの取り方

チュートリアルのゴール

Droongaクラスタのベンチマークを測定し、Groongaでの結果と比較するまでの、一連の手順を学ぶこと。

前提条件

ベンチマークの必要性について

DroongaはGroongaと互換性があるため、GroongaベースのアプリケーションをDroongaに移行することを検討することもあるでしょう。 そんな時は、実際に移行する前に、Droongaの性能を測定して、より良い移行先であるかどうかを確認しておくべきです。

もちろん、単にGroongaとDroongaの性能差を知りたいと思うこともあるでしょう。 ベンチマークによって、差を可視化することができます。

性能の可視化の方法

あるシステムの性能を表す指標としては、以下の2つが多く使われます。

応答時間とは、システムがリクエストを受け取ってからレスポンスを返すまでに実際にかかった時間のことです。 言い換えると、これは各リクエストについてクライアントが待たされた時間です。 この指標においては、数値は小さければ小さいほどよいです。 一般的に、クエリが軽い場合や、データベースのサイズが小さい場合、クライアント数が少ない場合に、応答時間は短くなります。

スループットは、一度にどれだけの数のリクエストを捌けるかを意味するものです。 性能の指標は「クエリ毎秒(Queries Per Second, qps)」という単位で表されます。 例えば、あるGroongaサーバが1秒に10件のリクエストを処理できたとき、これを「10qps」と表現します。 10人のユーザ(クライアント)がいるのかもしれませんし、2人のユーザがそれぞれブラウザ上で5つのタブを開いているのかもしれません。 ともかく、「10qps」という数値は、1秒が経過する間にそのGroongaサーバが実際に10件のリクエストを受け付けて、レスポンスを返したということを意味します。

ベンチマークは、drnbenchというGemパッケージによって導入されるdrnbench-request-responseコマンドで行うことができます。 このツールは、計測対象のサービスについて応答時間とスループットの両方を計測できます。

ベンチマークツールはどのように性能を測定するのか

drnbench-request-responseは、対象サービスの性能を以下のようにして計測します:

  1. マスタープロセスが仮想クライアントを1つ生成する。 このクライアントは即座に動き始め、対象サービスに対して多数のリクエストを連続して頻繁に送り続ける。
  2. しばらくしたら、マスタープロセスがクライアントを終了させる。 そして、応答のデータから最小・最大・平均の経過時間を計算する。 また、実際に対象サービスによって処理されたリクエストの件数を集計し、結果を1クライアントの場合のqps値として報告する。
  3. マスタープロセスが仮想クライアントを2つ生成する。 これらのクライアントはリクエストを送り始める。
  4. しばらくしたら、マスタープロセスがすべてのクライアントを終了させる。 そして、最小・最大・平均の経過時間を計算すると同時に、実際に対象サービスに処理されたリクエストの件数を集計し、結果を2クライアントの場合のqps値として報告する。
  5. 3クライアントの場合、4クライアントの場合……と、クライアント数を増やしながら繰り返す。
  6. 最後に、マスタープロセスが最小・最大・平均の経過時間、qps値、およびその他の情報をまとめたものを、以下のようなCSVファイルとして保存する:

    n_clients,total_n_requests,queries_per_second,min_elapsed_time,max_elapsed_time,average_elapsed_time,0,200
    1,164,5.466666666666667,0.002184631,1.951960432,0.1727086823963415,0,100.0
    2,1618,53.93333333333333,0.001466091,1.587372312,0.026789948272558754,0.12360939431396785,99.87639060568603
    4,4690,156.33333333333334,0.001065161,0.26070575,0.015224578191897657,0.042643923240938165,99.95735607675907
    6,6287,209.56666666666666,0.000923332,0.25709169,0.018191428254970568,0.09543502465404805,99.90456497534595
    8,6628,220.93333333333334,0.000979707,0.288406006,0.02557014875603507,0.030175015087507546,99.96982498491249
    10,7117,237.23333333333332,0.001235846,0.303093461,0.03160425060474918,0.1405086412814388,99.85949135871857
    12,7403,246.76666666666668,0.001111115,0.33163911,0.03792291040199917,0.09455626097528029,99.90544373902472
    14,7454,248.46666666666667,0.00151987,0.335161281,0.04522922885028168,0.174403005097934,99.82559699490207
    16,7357,245.23333333333332,0.000763487,0.356862003,0.05435767224085904,0.08155498165012913,99.91844501834987
    18,7494,249.8,0.001017168,0.378661333,0.061178927504003194,0.20016012810248196,99.79983987189752
    20,7506,250.2,0.001759464,0.404634447,0.06887332192845741,0.21316280309086064,99.78683719690913
    

    この結果は、分析や、グラフ描画など、様々な使い方ができます。

    (注意: 性能測定の結果は様々な要因によって変動します。 これはあくまで特定のバージョン、特定の環境での結果の例です。)

結果の読み方と分析の仕方

上の例を見て下さい。

経過時間(応答時間)は簡単に分析できます。値が小さければ小さいほどよいと言えます。 対象サービスのキャッシュ機構が正常に動作している場合、最小と平均の応答時間は小さくなります。 最大応答時間は、重たいクエリ、システムのメモリのスワップの発生、意図しないエラーの発生などの影響を受けます。

最後の2つの列、0200も見て下さい。 これらはHTTPレスポンスのステータスの割合を示しています。 200は「OK」、0は「タイムアウト」です。 400500などのエラーレスポンスが得られた場合も、同様に報告されます。 これらの情報は、意図しない速度低下の原因究明に役立つでしょう。 (各段階の終了時に進行中だったリクエストが強制中断され、それらがタイムアウトとして報告されるため、この例では200は100%にはなっていません。)

スループットの分析には、グラフが便利です。

スループットのグラフ

12クライアントを超えたあたりで、qps値が250前後で頭打ちになっているのを見て取れるでしょう。 これは、計測対象のサービスが1秒あたり最大で250件のリクエストを処理できるということを意味しています。

言い直すと、この結果は「(ハードウェア、ソフトウェア、ネットワーク、データベースの大きさ、クエリの内容など、様々な要素をひっくるめた)このシステムのスループットの性能限界は250qpsである」という風に読み取ることができます。 もしサービスに対するリクエストの件数が増加しつつあり、この限界に近づいているようであれば、クエリの最適化やコンピュータ自体のアップグレードなど、何らかの対策を取ることを検討する必要があると言えます。

また、同じリクエストのパターンをGroongaとDroongaに送ることで、各システムの応答時間とqps値の上限(性能限界)を比較することができます。 もしDroongaのqps値がGroongaのそれよりも大きい(つまり、DroongaがGroongaよりも高いスループット性能を発揮している)のであれば、サービスのバックエンドをGroongaからDroongaに移行する根拠になり得ます。 また、異なるノード数での結果を比較すると、新しくノードを追加する際のコストパフォーマンスを分析することもできます。

ベンチマーク環境を用意する

新しいDroongaクラスタのために、以下の、互いにホスト名で名前解決できる4つのUbuntu 14.04LTSのサーバがあると仮定します:

1つはクライアント用で、残りの3つはDroongaノード用です。

比較対照のデータベース(およびそのデータソース)を用意する

もしすでにGroongaベースのサービスを運用しているのであれば、それ自体が比較対照となります。 この場合、Groongaデータベースの内容すべてをダンプ出力し、新しく用意したDroongaクラスタに流し込みさえすれば、性能比較を行えます。

特に運用中のサービスが無いということであれば、有効なベンチマークを取るために大量のデータを格納したデータベースを、対照として用意する必要があります。 wikipedia-searchリポジトリには、Wikipedia日本語版のページを格納したGroongaサーバ(およびDroongaクラスタ)を用意する手助けとなるスクリプトが含まれています。

では、Wikipediaのページを格納したGroongaデータベースを、node0のノードに準備しましょう。

  1. データベースのサイズを決める。 ベンチマーク測定のためには、十分に大きいサイズのデータベースを使う必要があります。

    • もしデータベースが小さすぎれば、Droongaのオーバーヘッドが相対的に大きくなるため、Droongaにとって過度に悲観的なベンチマーク結果となるでしょう。
    • もしデータベースが大きすぎれば、メモリのスワップが発生してシステムの性能がランダムに劣化するために、過度に不安定なベンチマーク結果となるでしょう。
    • 各ノードのメモリの搭載量が異なる場合、その中で最もメモリ搭載量が少ないノードに合わせてデータベースのサイズを決めるのが望ましいです。

    例えば、node0 (8GB RAM), node1 (8GB RAM), node2 (6GB RAM)の3つのノードがあるとすれば、データベースは6GBよりも小さくするべきです。

  2. インストール手順に従ってGroongaサーバをセットアップする。

    (on node0)
    % sudo apt-get -y install software-properties-common
    % sudo add-apt-repository -y universe
    % sudo add-apt-repository -y ppa:groonga/ppa
    % sudo apt-get update
    % sudo apt-get -y install groonga
    

    これでGroongaを利用できるようになります。.

  3. Rakeのタスク data:convert:groonga:ja を使って、Wikipediaのページのアーカイブをダウンロードし、Groongaのダンプファイルに変換する。 変換するレコード(ページ)の数は、環境変数 MAX_N_RECORDS(初期値は5000)で指定することができます。

    (on node0)
    % cd ~/
    % git clone https://github.com/droonga/wikipedia-search.git
    % cd wikipedia-search
    % bundle install
    % time (MAX_N_RECORDS=100000 bundle exec rake data:convert:groonga:ja \
                                   data/groonga/ja-pages.grn)
    

    アーカイブは非常に大きいため、ダウンロードと変換には時間がかかります。

    変換が終わったら、~/wikipedia-search/data/groonga/ja-pages.grnの位置にダンプファイルが生成されています。 新しいデータベースを作成し、ダンプファイルの内容を流し込みましょう。 この操作にも時間がかかります:

    (on node0)
    % mkdir -p $HOME/groonga/db/
    % groonga -n $HOME/groonga/db/db quit
    % time (cat ~/wikipedia-search/config/groonga/schema.grn | groonga $HOME/groonga/db/db)
    % time (cat ~/wikipedia-search/config/groonga/indexes.grn | groonga $HOME/groonga/db/db)
    % time (cat ~/wikipedia-search/data/groonga/ja-pages.grn | groonga $HOME/groonga/db/db)
    

    注意: レコードの数がデータベースのサイズに影響します。 参考までに、検証環境での結果を以下に示します:

    • 30万件のレコードから、1.1GBのデータベースができました。 データの変換には17分、流し込みには6分を要しました。
    • 150万件のレコードから、4.3GBのデータベースができました。 データの変換には53分、流し込みには64分を要しました。
  4. GroongaをHTTPサーバとして起動する

    (on node0)
    % groonga -p 10041 -d --protocol http $HOME/groonga/db/db
    

これで、このノードをベンチマーク測定の対照として使う準備が整いました。

Droongaクラスタをセットアップする

Droongaをすべてのノードにインストールします。 HTTP経由での動作をベンチマーク測定するので、droonga-enginedroonga-http-serverの両方をインストールする必要があります。

(on node0)
% host=node0
% curl https://raw.githubusercontent.com/droonga/droonga-engine/master/install.sh | \
    sudo HOST=$host bash
% curl https://raw.githubusercontent.com/droonga/droonga-http-server/master/install.sh | \
    sudo ENGINE_HOST=$host HOST=$host PORT=10042 bash
% sudo droonga-engine-catalog-generate \
    --hosts=node0,node1,node2
% sudo service droonga-engine start
% sudo service droonga-http-server start
(on node1)
% host=node1
...
(on node2)
% host=node2
...

注意: droonga-http-serverをGroongaとは別のポート番号で起動するために、ここではPORT環境変数を使って上記のようにして10042のポートで起動するように指定しています。

DroongaのHTTPサーバが動作しており、10042番のポートを監視していることと、3つのノードからなるクラスタとして動作していることを確認しておきましょう:

(on node0)
% sudo apt-get install -y jq
% curl "http://node0:10042/droonga/system/status" | jq .
{
  "nodes": {
    "node0:10031/droonga": {
      "live": true
    },
    "node1:10031/droonga": {
      "live": true
    },
    "node2:10031/droonga": {
      "live": true
    }
  }
}

GroongaからDroongaへとデータを同期する

次に、Droongaのデータベースを用意します。

grn2drnコマンドを使うと、Groongaのダンプ出力をDroonga用のメッセージに変換することができます。 コマンドを利用できるようにするために、Groongaサーバとなっているコンピュータにgrn2drn Gemパッケージをインストールしましょう。

(on node0)
% sudo gem install grn2drn

また、rroonga Gemパッケージの一部として導入されるgrndumpコマンドは、既存のGroongaのデータベースからすべてのデータを柔軟に取り出す機能を提供しています。 もし既存のGroongaサーバからデータを取り出そうとしているのであれば、事前にrroongaをインストールしておく必要があります。

(on Ubuntu server)
% sudo apt-get -y install software-properties-common
% sudo add-apt-repository -y universe
% sudo add-apt-repository -y ppa:groonga/ppa
% sudo apt-get update
% sudo apt-get -y install libgroonga-dev
% sudo gem install rroonga
(on CentOS server)
# rpm -ivh http://packages.groonga.org/centos/groonga-release-1.1.0-1.noarch.rpm
# yum -y makecache
# yum -y ruby-devel groonga-devel
# gem install rroonga

それでは、スキーマ定義とデータを別々にダンプ出力し、Droongaクラスタに流し込みましょう。

(on node0)
% time (grndump --no-dump-tables $HOME/groonga/db/db | \
          grn2drn | \
          droonga-send --server=node0 \
                       --report-throughput)
% time (grndump --no-dump-schema --no-dump-indexes $HOME/groonga/db/db | \
          grn2drn | \
          droonga-send --server=node0 \
                       --server=node1 \
                       --server=node2 \
                       --report-throughput)

スキーマ定義とインデックスの定義については単一のエンドポイントに送るように注意して下さい。 Droongaは複数のノードに並行してバラバラに送られたスキーマ変更コマンドをソートすることができないので、スキーマ定義のリクエストを複数のエンドポイントに流し込むと、データベースが壊れてしまいます。

この操作にも時間がかかります。 それが完了したら、10041ポートを監視するGroonga HTTPサーバと、10042ポートを監視するDroonga HTTPサーバの、2つのHTTPサーバがある状態となります。

クライアントをセットアップする

クライアントにするマシンには、ベンチマーク用のクライアントをインストールする必要があります。

node3をクライアントとして使うと仮定します:

(on node3)
% sudo apt-get update
% sudo apt-get -y upgrade
% sudo apt-get install -y ruby curl jq
% sudo gem install drnbench

リクエストパターンを用意する

ベンチマーク用のリクエストパターンファイルを用意しましょう。

キャッシュヒット率を決める

まず、キャッシュヒット率を決める必要があります。

もし既に運用中のGroongaベースのサービスがあるのであれば、以下のようにして、statusコマンドを使ってGroongaデータベースのキャッシュヒット率を調べることができます:

% curl "http://node0:10041/d/status" | jq .
[
  [
    0,
    1412326645.19701,
    3.76701354980469e-05
  ],
  {
    "max_command_version": 2,
    "alloc_count": 158,
    "starttime": 1412326485,
    "uptime": 160,
    "version": "4.0.6",
    "n_queries": 1000,
    "cache_hit_rate": 0.5,
    "command_version": 1,
    "default_command_version": 1
  }
]

キャッシュヒット率は"cache_hit_rate"として返却されます。 0.5は50%という意味で、レスポンスのうちの半分がキャッシュされた結果に基づいて返されているということです。

運用中のサービスが無いのであれば、ひとまずキャッシュヒット率は50%と過程すると良いでしょう。

GroongaとDroongaの性能を正確に比較するためには、キャッシュヒット率が実際の値に近くなるようにリクエストパターンを用意する必要があります。 さて、どのようにすればよいのでしょうか?

キャッシュヒット率は、N = 100 ÷ (キャッシュヒット率)という式で計算した、ユニーク(一意)なリクエストパターンの数で制御できます。 これは、GroongaとDroonga(droonga-http-server)が既定の状態で最大で100件までの結果をキャッシュするためです。 期待されるキャッシュヒット率が50%なのであれば、用意するべきユニークなリクエストの数はN = 100 ÷ 0.5 = 200と計算できます。

注意: 実際のキャッシュヒット率が0に近い場合、必要となるユニークなリクエストの件数が巨大になってしまいます。 このような場合は、キャッシュヒット率を0.01(1%)程度と見なすとよいでしょう。

リクエストパターンファイルの書式

drnbench-request-response用のリクエストパターンのリストは、HTTPリクエストのパスのリストであるプレーンテキスト形式で作成します。 以下はGroongaのselectコマンド用のリクエストの一覧の例です:

/d/select?command_version=2&table=Pages&limit=10&match_columns=title&output_columns=title&query=AAA
/d/select?command_version=2&table=Pages&limit=10&match_columns=title&output_columns=title&query=BBB
...

もし既存のGroongaベースのサービスを運用しているのであれば、リクエストパターンのリストは、実際のアクセスログやクエリログなどから生成するのが望ましいです。 実際のリクエストに近いパターンであるほど、システムの性能をより有効に測定できます。 ユニークなリクエストパターンを200件作るには、ログからユニークなリクエスト先パスを200件収集してくればOKです。

運用中のサービスが無い場合は、何らかの方法でリクエストパスのリストを作る必要があります。 詳しくは事項を参照して下さい。

検索語句のリストを用意する

200件のユニークなリクエストパターンを作るには、200個の語句を用意する必要があります。 しかも、それらはすべて実際にGroongaのデータベースで有効な検索結果を返すものでなくてはなりません。 もしランダムに生成した単語(例えばP2qyNJ9L, Hy4pLKc5, D5eftuTp……といった具合)を使った場合、ほとんどのリクエストに対して「ヒット無し」という検索結果が返されてしまうため、有効なベンチマーク結果を得ることができません。

こんな時のために、drnbench-extract-searchtermsというユーティリティコマンドがあります。 これは、以下のようにしてGroongaの検索結果から単語のリストを生成します:

% curl "http://node0:10041/d/select?command_version=2&table=Pages&limit=10&output_columns=title" | \
    drnbench-extract-searchterms
title1
title2
title3
...
title10

drnbench-extract-searchtermsは検索結果のレコードの最初の列の値を単語として取り出します。 200件の有効な検索語句を得るには、単にlimit=200と指定して検索結果を得ればOKです。

与えられた語句からリクエストパターンファイルを生成する

では、drnbench-extract-searchtermsを使って、Groongaの検索結果からリクエストパターンを生成してみましょう。

% n_unique_requests=200
% curl "http://node0:10041/d/select?command_version=2&table=Pages&limit=$n_unique_requests&output_columns=title" | \
    drnbench-extract-searchterms --escape | \
    sed -r -e "s;^;/d/select?command_version=2\&table=Pages\&limit=10\&match_columns=title,text\&output_columns=snippet_html(title),snippet_html(text),categories,_key\&query_flags=NONE\&query=;" \
    > ./patterns.txt

注意:

生成されたファイル patterns.txt は以下のような内容になります:

/d/select?command_version=2&table=Pages&limit=10&match_columns=title,text&output_columns=snippet_html(title),snippet_html(text),categories,_key&query_flags=NONE&query=AAA
/d/select?command_version=2&table=Pages&limit=10&match_columns=title,text&output_columns=snippet_html(title),snippet_html(text),categories,_key&query_flags=NONE&query=BBB
...

ベンチマークを実行する

以上で、準備が整いました。 それではGroongaとDroongaのベンチマークを取得してみましょう。

Groongaのベンチマークを行う

まず、比較対照としてGroongaでのベンチマーク結果を取得します。 node0を比較対照用のGroongaサーバとしてセットアップ済みで、GroongaのHTTPサーバが停止している場合には、ベンチマークの実行前にあらかじめ起動しておいて下さい。

(on node0)
% groonga -p 10041 -d --protocol http $HOME/groonga/db/db

ベンチマークは以下の要領で、drnbench-request-responseコマンドを実行すると測定できます:

(on node3)
% drnbench-request-response \
    --step=2 \
    --start-n-clients=0 \
    --end-n-clients=20 \
    --duration=30 \
    --interval=10 \
    --request-patterns-file=$PWD/patterns.txt \
    --default-hosts=node0 \
    --default-port=10041 \
    --output-path=$PWD/groonga-result.csv

重要なパラメータは以下の通りです:

これで、対照用のGroongaでの結果を得る事ができます。 Droongaノードの上でGroongaを動かしている場合は、CPU資源とメモリ資源を解放するために、ベンチマーク取得後はGroongaを停止しておきましょう。

(on node0)
% pkill groonga

Droongaのベンチマークを行う

1ノード構成でのDroongaのベンチマーク

ベンチマークの前に、ノードが1つだけの状態にクラスタを設定します。

(on node0)
% sudo droonga-engine-catalog-generate \
    --hosts=node0
% sudo service droonga-engine restart
% sudo service droonga-http-server restart

前回のベンチマークの影響をなくすために、各ベンチマークの実行前にはサービスを再起動することをおすすめします。

これにより、node0は1ノード構成のクラスタとして動作するようになります。 実際にノードが1つだけ認識されていることを確認しましょう:

(on node3)
% curl "http://node0:10042/droonga/system/status" | jq .
{
  "nodes": {
    "node0:10031/droonga": {
      "live": true
    }
  }
}

ベンチマークを実行しましょう。

(on node3)
% drnbench-request-response \
    --step=2 \
    --start-n-clients=0 \
    --end-n-clients=20 \
    --duration=30 \
    --interval=10 \
    --request-patterns-file=$PWD/patterns.txt \
    --default-hosts=node0 \
    --default-port=10042 \
    --output-path=$PWD/droonga-result-1node.csv

デフォルトのポートが10041(GroongaのHTTPサーバのポート)から10042(Droongaのポート)に変わっていることに注意して下さい。 結果の保存先のパスも変わっています。

また、チュートリアルの実行中、node0のシステムの状態をtopコマンドなどを使って監視することもお勧めします。 この作業は、ボトルネックの分析に役に立つかもしれません。

2ノード構成でのDroongaのベンチマーク

ベンチマークの前に、2番目のノードをクラスタに参加させます。

(on node0, node1)
% sudo droonga-engine-catalog-generate \
    --hosts=node0,node1
% sudo service droonga-engine restart
% sudo service droonga-http-server restart

これにより、node0node1は2ノード構成のDroongaクラスタとして動作するようになります。 実際にノードが2つ認識されていることを確認しましょう:

(on node3)
% curl "http://node0:10042/droonga/system/status" | jq .
{
  "nodes": {
    "node0:10031/droonga": {
      "live": true
    },
    "node1:10031/droonga": {
      "live": true
    }
  }
}

ベンチマークを実行しましょう。

(on node3)
% drnbench-request-response \
    --step=2 \
    --start-n-clients=0 \
    --end-n-clients=20 \
    --duration=30 \
    --interval=10 \
    --request-patterns-file=$PWD/patterns.txt \
    --default-hosts=node0,node1 \
    --default-port=10042 \
    --output-path=$PWD/droonga-result-2nodes.csv

--default-hosts で2つのホストを指定していることに注意して下さい。

今の所、droonga-http-serverはシングルプロセスのため、すべてのリクエストを1つだけのホストに送るとdroonga-http-serverがボトルネックとなってしまいます。 また、droonga-http-serverdroonga-engineがCPU資源を奪い合うことにもなります。 Droongaクラスタの性能を有効に測定するためには、各ノードのCPU使用率を平滑化する必要があります。

もちろん、実際のプロダクション環境ではこのようなリクエストの分配はロードバランサーによって行われるべきですが、ベンチマークのためだけにロードバランサーを設定するのは煩雑です。 --default-hostsオプションにカンマ区切りで複数のホスト名を指定することで、その代替とすることができます。

また、結果の保存先のパスも変えています。各ノードのシステムの状態を監視することも忘れないで下さい。

3ノード構成でのDroongaのベンチマーク

ベンチマークの前に、最後のノードをクラスタに参加させましょう。

(on node0, node1)
% sudo droonga-engine-catalog-generate \
    --hosts=node0,node1,node2
% sudo service droonga-engine restart
% sudo service droonga-http-server restart

これで、node0, node1, node2のすべてのノードが3ノード構成のクラスタとして動作するようになります。 実際にノードが3つ認識されていることを確認しましょう:

(on node3)
% curl "http://node0:10042/droonga/system/status" | jq .
{
  "nodes": {
    "node0:10031/droonga": {
      "live": true
    },
    "node1:10031/droonga": {
      "live": true
    },
    "node2:10031/droonga": {
      "live": true
    }
  }
}

ベンチマークを実行しましょう。

(on node3)
% drnbench-request-response \
    --step=2 \
    --start-n-clients=0 \
    --end-n-clients=20 \
    --duration=30 \
    --interval=10 \
    --request-patterns-file=$PWD/patterns.txt \
    --default-hosts=node0,node1,node2 \
    --default-port=10042 \
    --output-path=$PWD/droonga-result-3nodes.csv

また--default-hosts--output-pathの指定も変えていることに注意して下さい。 各ノードのシステムの状態を監視することもやはり重要です。

結果を分析する

これで、手元に4つの結果が集まりました:

先に述べた通り、これらを使って傾向を分析することができます。

例えば、これらの結果は以下のようにグラフ化できます:

それぞれの場合のスループットを重ねたグラフ

このグラフは、「この条件下では、Droongaは複数ノードであれば良い性能が出ている」「この設定だと、1ノード構成ではDroongaの性能はGroongaに及ばない」などのように読み取ることができます。

(注意: 性能測定の結果は様々な要因によって変動します。 これはあくまで特定のバージョン、特定の環境での結果の例です。)

まとめ

このチュートリアルでは、比較対照としてのGroongaサーバと、Droongaクラスタを用意しました。 また、リクエストパターンを用意する手順、システムの性能の測定方法、結果の分析方法なども学びました。