YUKI Hiroshi
null+****@clear*****
Fri Nov 28 17:20:23 JST 2014
YUKI Hiroshi 2014-11-28 17:20:23 +0900 (Fri, 28 Nov 2014) New Revision: 5cea8f9abe8f1e9f3e3a75fffcd10917bda91857 https://github.com/droonga/droonga.org/commit/5cea8f9abe8f1e9f3e3a75fffcd10917bda91857 Message: Add steps to check the benchmark correctly measures the performance or not Modified files: _po/ja/tutorial/1.0.8/benchmark/index.po ja/tutorial/1.0.7/benchmark/index.md ja/tutorial/1.0.8/benchmark/index.md tutorial/1.0.8/benchmark/index.md Modified: _po/ja/tutorial/1.0.8/benchmark/index.po (+14 -1) =================================================================== --- _po/ja/tutorial/1.0.8/benchmark/index.po 2014-11-28 17:05:26 +0900 (d39e489) +++ _po/ja/tutorial/1.0.8/benchmark/index.po 2014-11-28 17:20:23 +0900 (33e2f46) @@ -992,6 +992,19 @@ msgstr "" " * `--output-path` は、結果の出力先ファイルへのパスです。\n" " すべてのベンチマークの統計情報が、この位置にファイルとして保存されます。" +msgid "" +"While running, you should monitor the system status of the `node0`, by `top` o" +"r something.\n" +"If the benchmark elicits Groonga's performance correctly, Groonga's process us" +"es the CPU fully (for example, `400%` on a computer with 4 processors).\n" +"Otherwise something wrong - for example, too narrow network, too low performan" +"ce client." +msgstr "" +"ベンチマークの実行中は、`node0`のシステムの状態を`top`コマンドなどを使って監視しておきましょう。\n" +"もしベンチマークがGroongaの性能を正しく引き出していれば、GroongaのプロセスはCPUをフルに使い切っているはずです（プロセッサ数4ならば`400" +"%`、といった具合に）。\n" +"そうでない場合は、何かがおかしいです。例えばネットワーク帯域が細すぎるのかもしれませんし、クライアントが非力すぎるのかもしれません。" + msgid "Then you'll get the reference result of the Groonga." msgstr "これで、対照用のGroongaでの結果を得る事ができます。" @@ -1132,7 +1145,7 @@ msgid "" "op` or something.\n" "It may help you to analyze what is the bottleneck." msgstr "" -"また、チュートリアルの実行中、`node0`のシステムの状態を`top`コマンドなどを使って監視することもお勧めします。\n" +"また、ベンチマークの実行中、`node0`のシステムの状態を`top`コマンドなどを使って監視することもお勧めします。\n" "この作業は、ボトルネックの分析に役に立つかもしれません。" msgid "#### Benchmark Droonga with two nodes" Modified: ja/tutorial/1.0.7/benchmark/index.md (+1 -1) =================================================================== --- ja/tutorial/1.0.7/benchmark/index.md 2014-11-28 17:05:26 +0900 (4584217) +++ ja/tutorial/1.0.7/benchmark/index.md 2014-11-28 17:20:23 +0900 (1f1f75b) @@ -568,7 +568,7 @@ Droongaノードの上でGroongaを動かしている場合は、CPU資源とメ デフォルトのポートが`10041`（GroongaのHTTPサーバのポート）から`10042`（Droongaのポート）に変わっていることに注意して下さい。 結果の保存先のパスも変わっています。 -また、チュートリアルの実行中、`node0`のシステムの状態を`top`コマンドなどを使って監視することもお勧めします。 +また、ベンチマークの実行中、`node0`のシステムの状態を`top`コマンドなどを使って監視することもお勧めします。 この作業は、ボトルネックの分析に役に立つかもしれません。 #### 2ノード構成でのDroongaのベンチマーク Modified: ja/tutorial/1.0.8/benchmark/index.md (+44 -1) =================================================================== --- ja/tutorial/1.0.8/benchmark/index.md 2014-11-28 17:05:26 +0900 (ed4bf4e) +++ ja/tutorial/1.0.8/benchmark/index.md 2014-11-28 17:20:23 +0900 (4e45c1e) @@ -515,6 +515,10 @@ title10 * `--output-path` は、結果の出力先ファイルへのパスです。 すべてのベンチマークの統計情報が、この位置にファイルとして保存されます。 +ベンチマークの実行中は、`node0`のシステムの状態を`top`コマンドなどを使って監視しておきましょう。 +もしベンチマークがGroongaの性能を正しく引き出していれば、GroongaのプロセスはCPUをフルに使い切っているはずです（プロセッサ数4ならば`400%`、といった具合に）。 +そうでない場合は、何かがおかしいです。例えばネットワーク帯域が細すぎるのかもしれませんし、クライアントが非力すぎるのかもしれません。 + これで、対照用のGroongaでの結果を得る事ができます。 結果が妥当かどうかを確かめるために、`status`コマンドの結果を確認しましょう： @@ -609,9 +613,48 @@ Droongaノードの上でGroongaを動かしている場合は、CPU資源とメ デフォルトのポートが`10041`（GroongaのHTTPサーバのポート）から`10042`（Droongaのポート）に変わっていることに注意して下さい。 結果の保存先のパスも変わっています。 -また、チュートリアルの実行中、`node0`のシステムの状態を`top`コマンドなどを使って監視することもお勧めします。 +また、ベンチマークの実行中、`node0`のシステムの状態を`top`コマンドなどを使って監視することもお勧めします。 この作業は、ボトルネックの分析に役に立つかもしれません。 + + + + + + +結果が妥当かどうかを確かめるために、`status`コマンドの結果を確認しましょう： + +~~~ +% 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.49, + "command_version": 1, + "default_command_version": 1 + } +] +~~~ + +`"cache_hit_rate"`の値に注目してください。 +この値が想定されるキャッシュ率（例えば`0.5`）からかけ離れている場合、何かがおかしいです。例えば、リクエストパターンの数が少なすぎるかも知れません。 +キャッシュヒット率が高すぎる場合、結果のスループットは本来よりも高すぎる値になってしまいます。 + + + + + + #### 2ノード構成でのDroongaのベンチマーク ベンチマークの前に、2番目のノードをクラスタに参加させます。 Modified: tutorial/1.0.8/benchmark/index.md (+43 -0) =================================================================== --- tutorial/1.0.8/benchmark/index.md 2014-11-28 17:05:26 +0900 (6d26abd) +++ tutorial/1.0.8/benchmark/index.md 2014-11-28 17:20:23 +0900 (e52859f) @@ -506,6 +506,10 @@ Important parameters are: * `--output-path` is the path to the result file. Statistics of all benchmarks is saved as a file at the location. +While running, you should monitor the system status of the `node0`, by `top` or something. +If the benchmark elicits Groonga's performance correctly, Groonga's process uses the CPU fully (for example, `400%` on a computer with 4 processors). +Otherwise something wrong - for example, too narrow network, too low performance client. + Then you'll get the reference result of the Groonga. To confirm the result is valid, check the response of the `status` command: @@ -603,6 +607,45 @@ Moreover, the path to the result file also changed. And, while running, you should monitor the system status of the `node0`, by `top` or something. It may help you to analyze what is the bottleneck. + + + + + + +To confirm the result is valid, check the response of the `status` command: + +~~~ +% 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.49, + "command_version": 1, + "default_command_version": 1 + } +] +~~~ + +Look at the value of `"cache_hit_rate"`. +If it is far from the expected cache hit rate (ex. `0.5`), something wrong - for example, too few request patterns. +Too high cache hit rate produces too high throughput unexpectedly. + + + + + + #### Benchmark Droonga with two nodes Before benchmarking, join the second node to the cluster. -------------- next part -------------- HTML����������������������������...下載
