YUKI Hiroshi
null+****@clear*****
Fri Nov 28 17:38:57 JST 2014
YUKI Hiroshi 2014-11-28 17:38:57 +0900 (Fri, 28 Nov 2014) New Revision: d023fc9f15c7bcd22ce47985529a0f0a350e3546 https://github.com/droonga/droonga.org/commit/d023fc9f15c7bcd22ce47985529a0f0a350e3546 Message: Add steps to confirm the result 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 (+38 -7) =================================================================== --- _po/ja/tutorial/1.0.8/benchmark/index.po 2014-11-28 17:20:23 +0900 (33e2f46) +++ _po/ja/tutorial/1.0.8/benchmark/index.po 2014-11-28 17:38:57 +0900 (1295b57) @@ -1141,12 +1141,38 @@ msgstr "" "結果の保存先のパスも変わっています。" msgid "" -"And, while running, you should monitor the system status of the `node0`, by `t" -"op` or something.\n" +"While running, you should monitor the system status of the `node0`, by `top` o" +"r something.\n" "It may help you to analyze what is the bottleneck." msgstr "" -"また、ベンチマークの実行中、`node0`のシステムの状態を`top`コマンドなどを使って監視することもお勧めします。\n" -"この作業は、ボトルネックの分析に役に立つかもしれません。" +"ベンチマークの実行中、`node0`のシステムの状態を`top`コマンドなどで監視しておきましょう。\n" +"これはボトルネックの分析に役立ちます。" + +msgid "" +"And, to confirm the result is valid, you should check the actual cache hit rat" +"e:" +msgstr "また、結果が正しいかどうかを確かめるために、実際のキャッシュヒット率を確認しておきましょう：" + +msgid "" +"~~~\n" +"% curl \"http://node0:10042/statistics/cache\" | jq .\n" +"{\n" +" \"hitRatio\": 49.830717830807124,\n" +" \"nHits\": 66968,\n" +" \"nGets\": 134391\n" +"}\n" +"~~~" +msgstr "" + +msgid "" +"Look at the value of `\"hitRatio\"`.\n" +"Actual cache hit rate of the HTTP server is reported in percentage like above " +"(the value `49.830717830807124` means `49.830717830807124%`.)\n" +"If it is far from the expected cache hit rate, something wrong." +msgstr "" +"`\"hitRatio\"`の値に注目してください。HTTPサーバにおける実際のキャッシュヒット率は、上記のようにパーセンテージで示されます（`49.83071" +"7830807124`という値はそのまま`49.830717830807124%`ということです）。\n" +"もし値が期待されるキャッシュヒット率と大きく異なっている場合、何かがおかしいです。" msgid "#### Benchmark Droonga with two nodes" msgstr "#### 2ノード構成でのDroongaのベンチマーク" @@ -1231,10 +1257,15 @@ msgstr "" "するのは煩雑です。\n" "`--default-hosts`オプションにカンマ区切りで複数のホスト名を指定することで、その代替とすることができます。" +msgid "And, the path to the result file also changed." +msgstr "また、結果の保存先のパスも変えています。" + msgid "" -"And, the path to the result file also changed.\n" -"Don't forget to monitor system status of both nodes also." -msgstr "また、結果の保存先のパスも変えています。各ノードのシステムの状態を監視することも忘れないで下さい。" +"Don't forget to monitor system status of both nodes while benchmarking.\n" +"If only one node is busy and another is idling, something wrong - for example," +" they are not working as a cluster.\n" +"You also must check the actual cache hit rate of all nodes." +msgstr "" msgid "#### Benchmark Droonga with three nodes" msgstr "#### 3ノード構成でのDroongaのベンチマーク" Modified: ja/tutorial/1.0.7/benchmark/index.md (+1 -1) =================================================================== --- ja/tutorial/1.0.7/benchmark/index.md 2014-11-28 17:20:23 +0900 (1f1f75b) +++ ja/tutorial/1.0.7/benchmark/index.md 2014-11-28 17:38:57 +0900 (4584217) @@ -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 (+15 -37) =================================================================== --- ja/tutorial/1.0.8/benchmark/index.md 2014-11-28 17:20:23 +0900 (4e45c1e) +++ ja/tutorial/1.0.8/benchmark/index.md 2014-11-28 17:38:57 +0900 (5ece28d) @@ -613,47 +613,22 @@ 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 - } -] +% curl "http://node0:10042/statistics/cache" | jq . +{ + "hitRatio": 49.830717830807124, + "nHits": 66968, + "nGets": 134391 +} ~~~ -`"cache_hit_rate"`の値に注目してください。 -この値が想定されるキャッシュ率（例えば`0.5`）からかけ離れている場合、何かがおかしいです。例えば、リクエストパターンの数が少なすぎるかも知れません。 -キャッシュヒット率が高すぎる場合、結果のスループットは本来よりも高すぎる値になってしまいます。 - - - - - +`"hitRatio"`の値に注目してください。HTTPサーバにおける実際のキャッシュヒット率は、上記のようにパーセンテージで示されます（`49.830717830807124`という値はそのまま`49.830717830807124%`ということです）。 +もし値が期待されるキャッシュヒット率と大きく異なっている場合、何かがおかしいです。 #### 2ノード構成でのDroongaのベンチマーク @@ -710,8 +685,11 @@ Droongaクラスタの性能を有効に測定するためには、各ノード もちろん、実際のプロダクション環境ではこのようなリクエストの分配はロードバランサーによって行われるべきですが、ベンチマークのためだけにロードバランサーを設定するのは煩雑です。 `--default-hosts`オプションにカンマ区切りで複数のホスト名を指定することで、その代替とすることができます。 -また、結果の保存先のパスも変えています。各ノードのシステムの状態を監視することも忘れないで下さい。 +また、結果の保存先のパスも変えています。 +Don't forget to monitor system status of both nodes while benchmarking. +If only one node is busy and another is idling, something wrong - for example, they are not working as a cluster. +You also must check the actual cache hit rate of all nodes. #### 3ノード構成でのDroongaのベンチマーク Modified: tutorial/1.0.8/benchmark/index.md (+14 -36) =================================================================== --- tutorial/1.0.8/benchmark/index.md 2014-11-28 17:20:23 +0900 (e52859f) +++ tutorial/1.0.8/benchmark/index.md 2014-11-28 17:38:57 +0900 (db5a18a) @@ -604,47 +604,23 @@ Run the benchmark. Note that the default port is changed from `10041` (Groonga's HTTP server) to `10042` (Droonga). 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. +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: +And, to confirm the result is valid, you should check the actual cache hit rate: ~~~ -% 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 - } -] +% curl "http://node0:10042/statistics/cache" | jq . +{ + "hitRatio": 49.830717830807124, + "nHits": 66968, + "nGets": 134391 +} ~~~ -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. - - - - - +Look at the value of `"hitRatio"`. +Actual cache hit rate of the HTTP server is reported in percentage like above (the value `49.830717830807124` means `49.830717830807124%`.) +If it is far from the expected cache hit rate, something wrong. #### Benchmark Droonga with two nodes @@ -702,8 +678,10 @@ Of course, on the production environment, it should be done by a load balancer, Instead, you can specify multiple endpoint host names as a comma-separated list for the `--default-hosts` option. And, the path to the result file also changed. -Don't forget to monitor system status of both nodes also. +Don't forget to monitor system status of both nodes while benchmarking. +If only one node is busy and another is idling, something wrong - for example, they are not working as a cluster. +You also must check the actual cache hit rate of all nodes. #### Benchmark Droonga with three nodes -------------- next part -------------- HTML����������������������������...Download