SHIMODA Piro Hiroshi
null+****@clear*****
Sat Oct 4 12:43:38 JST 2014
SHIMODA "Piro" Hiroshi 2014-10-04 12:43:38 +0900 (Sat, 04 Oct 2014) New Revision: e7ad93517791592726dd425a25db2b3f0326e3ea https://github.com/droonga/droonga.org/commit/e7ad93517791592726dd425a25db2b3f0326e3ea Message: Update descriptions how to analyze the result Modified files: _po/ja/tutorial/1.0.7/benchmark/index.po ja/tutorial/1.0.7/benchmark/index.md tutorial/1.0.7/benchmark/index.md Modified: _po/ja/tutorial/1.0.7/benchmark/index.po (+36 -7) =================================================================== --- _po/ja/tutorial/1.0.7/benchmark/index.po 2014-10-04 12:20:59 +0900 (d4b56d2) +++ _po/ja/tutorial/1.0.7/benchmark/index.po 2014-10-04 12:43:38 +0900 (df63fb8) @@ -224,16 +224,45 @@ msgstr "" msgid "### How read and analyze the result? {#how-to-analyze}" msgstr "### 結果の読み方と分析の仕方 {#how-to-analyze}" +msgid "Look at the result above." +msgstr "上の例を見て下さい。" + +msgid "" +"Elapsed response time is easily analyzed - the smaller is the better.\n" +"The minimum and average response time becomes small if any cache system is wor" +"king correctly on the target.\n" +"The maximum time is affected by slow queries, system's page-in/page-out, unexp" +"ected errors, and so on," +msgstr "" +"経過時間（応答時間）は簡単に分析できます。値が小さければ小さいほどよいと言えます。\n" +"対象サービスのキャッシュ機構が正常に動作している場合、最小と平均の応答時間は小さくなります。\n" +"最大応答時間は、重たいクエリ、システムのメモリのスワップの発生、意図しないエラーの発生などの影響を受けます。" + +msgid "" +"See also the last two columns, `0` and `200`.\n" +"They mean the percentage of HTTP response statuses.\n" +"`200` is \"OK\", `0` is \"timed out\".\n" +"In this case, because some requests are timed out by some reasons, `200` is no" +"t 100% in many cases.\n" +"These information will help you to detect unexpected slow down." +msgstr "" +"最後の2つの列、`0`と`200`も見て下さい。\n" +"これらはHTTPレスポンスのステータスの割合を示しています。\n" +"`200`は「OK」、`0`は「タイムアウト」です。\n" +"この例では、いくつかのリクエストが何らかの理由でタイムアウトしているために、`200`は100%にはなっていません。\n" +"これらの情報は、意図しない速度低下の原因究明に役立つでしょう。" + +msgid "To analyze throughput, a graph is useful." +msgstr "スループットの分析には、グラフが便利です。" + msgid "" msgstr "" msgid "" -"Look at the result above, and this graph.\n" "You'll see that the \"qps\" stagnated around 250, for 12 or more clients.\n" "This means that the target service can process 250 requests in one second, at " "a maximum." msgstr "" -"先の例と、このグラフを見て下さい。\n" "12クライアントを超えたあたりで、qps値が250前後で頭打ちになっているのを見て取れるでしょう。\n" "これは、計測対象のサービスが1秒あたり最大で250件のリクエストを処理できるということを意味しています。" @@ -251,15 +280,15 @@ msgstr "" "を取ることを検討する必要があると言えます。" msgid "" -"And, sending same request patterns to Groonga and Droonga, you can compare max" -"imum \"qps\" for each system.\n" +"And, sending same request patterns to Groonga and Droonga, you can compare res" +"ponse times and maximum \"qps\" for each system.\n" "If Droonga's \"qps\" is larger than Groonga's one (=Droonga has better performan" "ce about throughput), it will become good reason to migrate your service from " "Groogna to Droonga.\n" "Moreover, comparing multiple results from different number of Droogna nodes, y" "ou can analyze the cost-benefit performance for newly introduced nodes." msgstr "" -"また、同じリクエストのパターンをGroongaとDroongaに送ることで、各システムのqps値の上限（性能限界）を比較することができます。\n" +"また、同じリクエストのパターンをGroongaとDroongaに送ることで、各システムの応答時間とqps値の上限（性能限界）を比較することができます。\n" "もしDroongaのqps値がGroongaのそれよりも大きい（つまり、DroongaがGroongaよりも高いスループット性能を発揮している）のであれば、" "サービスのバックエンドをGroongaからDroongaに移行する根拠になり得ます。\n" "また、異なるノード数での結果を比較すると、新しくノードを追加する際のコストパフォーマンスを分析することもできます。" @@ -301,8 +330,8 @@ msgstr "" msgid "" " * If it is too small, you'll see \"too bad\" benchmark result for Droonga, b" "ecause the percentage of the Droonga's overhead becomes relatively too large.\n" -" * If it is too large, you'll see \"too unstable\" result because swapping of" -" RAM will slow the performance down randomly.\n" +" * If it is too large, you'll see \"too unstable\" result because page-in and" +" page-out of RAM will slow the performance down randomly.\n" " * If RAM size of all nodes are different, you should determine the size of" " the database for the minimum size RAM." msgstr "" Modified: ja/tutorial/1.0.7/benchmark/index.md (+15 -2) =================================================================== --- ja/tutorial/1.0.7/benchmark/index.md 2014-10-04 12:20:59 +0900 (f34044a) +++ ja/tutorial/1.0.7/benchmark/index.md 2014-10-04 12:43:38 +0900 (2ad45a0) @@ -108,16 +108,29 @@ DroongaはGroongaと互換性があるため、Groongaベースのアプリケ ### 結果の読み方と分析の仕方 {#how-to-analyze} +上の例を見て下さい。 + +経過時間（応答時間）は簡単に分析できます。値が小さければ小さいほどよいと言えます。 +対象サービスのキャッシュ機構が正常に動作している場合、最小と平均の応答時間は小さくなります。 +最大応答時間は、重たいクエリ、システムのメモリのスワップの発生、意図しないエラーの発生などの影響を受けます。 + +最後の2つの列、`0`と`200`も見て下さい。 +これらはHTTPレスポンスのステータスの割合を示しています。 +`200`は「OK」、`0`は「タイムアウト」です。 +この例では、いくつかのリクエストが何らかの理由でタイムアウトしているために、`200`は100%にはなっていません。 +これらの情報は、意図しない速度低下の原因究明に役立つでしょう。 + +スループットの分析には、グラフが便利です。 +  -先の例と、このグラフを見て下さい。 12クライアントを超えたあたりで、qps値が250前後で頭打ちになっているのを見て取れるでしょう。 これは、計測対象のサービスが1秒あたり最大で250件のリクエストを処理できるということを意味しています。 言い直すと、この結果は「（ハードウェア、ソフトウェア、ネットワーク、データベースの大きさ、クエリの内容など、様々な要素をひっくるめた）このシステムのスループットの性能限界は250qpsである」という風に読み取ることができます。 もしサービスに対するリクエストの件数が増加しつつあり、この限界に近づいているようであれば、クエリの最適化やコンピュータ自体のアップグレードなど、何らかの対策を取ることを検討する必要があると言えます。 -また、同じリクエストのパターンをGroongaとDroongaに送ることで、各システムのqps値の上限（性能限界）を比較することができます。 +また、同じリクエストのパターンをGroongaとDroongaに送ることで、各システムの応答時間とqps値の上限（性能限界）を比較することができます。 もしDroongaのqps値がGroongaのそれよりも大きい（つまり、DroongaがGroongaよりも高いスループット性能を発揮している）のであれば、サービスのバックエンドをGroongaからDroongaに移行する根拠になり得ます。 また、異なるノード数での結果を比較すると、新しくノードを追加する際のコストパフォーマンスを分析することもできます。 Modified: tutorial/1.0.7/benchmark/index.md (+16 -3) =================================================================== --- tutorial/1.0.7/benchmark/index.md 2014-10-04 12:20:59 +0900 (821e3c4) +++ tutorial/1.0.7/benchmark/index.md 2014-10-04 12:43:38 +0900 (b536bf7) @@ -99,16 +99,29 @@ It measures both response time and throughput of the target service. ### How read and analyze the result? {#how-to-analyze} +Look at the result above. + +Elapsed response time is easily analyzed - the smaller is the better. +The minimum and average response time becomes small if any cache system is working correctly on the target. +The maximum time is affected by slow queries, system's page-in/page-out, unexpected errors, and so on, + +See also the last two columns, `0` and `200`. +They mean the percentage of HTTP response statuses. +`200` is "OK", `0` is "timed out". +In this case, because some requests are timed out by some reasons, `200` is not 100% in many cases. +These information will help you to detect unexpected slow down. + +To analyze throughput, a graph is useful. +  -Look at the result above, and this graph. You'll see that the "qps" stagnated around 250, for 12 or more clients. This means that the target service can process 250 requests in one second, at a maximum. In other words, we can describe the result as: 250qps is the maximum throughput performance of this system - generic performance of hardware, software, network, size of the database, queries, and more. If the number of requests for your service is growing up and it is going to reach the limit, you have to do something about it - optimize queries, replace the computer with more powerful one, and so on. -And, sending same request patterns to Groonga and Droonga, you can compare maximum "qps" for each system. +And, sending same request patterns to Groonga and Droonga, you can compare response times and maximum "qps" for each system. If Droonga's "qps" is larger than Groonga's one (=Droonga has better performance about throughput), it will become good reason to migrate your service from Groogna to Droonga. Moreover, comparing multiple results from different number of Droogna nodes, you can analyze the cost-benefit performance for newly introduced nodes. @@ -127,7 +140,7 @@ So let's prepare a new Groonga database including Wikipedia pages, on a node `19 You have to use good enough size database for benchmarking. * If it is too small, you'll see "too bad" benchmark result for Droonga, because the percentage of the Droonga's overhead becomes relatively too large. - * If it is too large, you'll see "too unstable" result because swapping of RAM will slow the performance down randomly. + * If it is too large, you'll see "too unstable" result because page-in and page-out of RAM will slow the performance down randomly. * If RAM size of all nodes are different, you should determine the size of the database for the minimum size RAM. For example, if there are three nodes `192.168.100.50` (8GB RAM), `192.168.100.51` (8GB RAM), and `192.168.100.52` (6GB RAM), then the database should be smaller than 6GB. -------------- next part -------------- HTML����������������������������...ダウンロード
