YUKI Hiroshi
null+****@clear*****
Sat Nov 29 00:33:33 JST 2014
YUKI Hiroshi 2014-11-29 00:33:33 +0900 (Sat, 29 Nov 2014) New Revision: 41e24c14e793ba01b4e517cb6503a48f1c44c507 https://github.com/droonga/droonga.org/commit/41e24c14e793ba01b4e517cb6503a48f1c44c507 Message: Update descriptions based on latest result Modified files: _po/ja/tutorial/1.0.8/benchmark/index.po 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 (+36 -35) =================================================================== --- _po/ja/tutorial/1.0.8/benchmark/index.po 2014-11-28 17:44:11 +0900 (d23cd54) +++ _po/ja/tutorial/1.0.8/benchmark/index.po 2014-11-29 00:33:33 +0900 (0eb8542) @@ -82,24 +82,24 @@ msgid "There are two major indexes to indicate performance of a system." msgstr "あるシステムの性能を表す指標としては、以下の2つが多く使われます。" msgid "" -" * response time\n" +" * latency\n" " * throughput" msgstr "" -" * 応答時間\n" +" * レイテンシー\n" " * スループット" msgid "" -"Response time is the actual elapsed time between two moments: when the system " -"receives a request, and when it returns a response.\n" +"Latency is the response time, actual elapsed time between two moments: when th" +"e system receives a request, and when it returns a response.\n" "In other words, for clients, it is the time to wait for each request.\n" "At this index, the smaller is the better.\n" -"In general, response time becomes small for lightweight queries, small size da" -"tabase, or less clients." +"In general, latency becomes small for lightweight queries, small size database" +", or less clients." msgstr "" -"応答時間とは、システムがリクエストを受け取ってからレスポンスを返すまでに実際にかかった時間のことです。\n" +"レイテンシーとは、システムがリクエストを受け取ってからレスポンスを返すまでに実際にかかった応答時間のことです。\n" "言い換えると、これは各リクエストについてクライアントが待たされた時間です。\n" "この指標においては、数値は小さければ小さいほどよいです。\n" -"一般的に、クエリが軽い場合や、データベースのサイズが小さい場合、クライアント数が少ない場合に、応答時間は短くなります。" +"一般的に、クエリが軽い場合や、データベースのサイズが小さい場合、クライアント数が少ない場合に、レイテンシーは小さくなります。" msgid "" "Throughput means how many request can be processed in a time.\n" @@ -121,11 +121,11 @@ msgstr "" msgid "" "You can run benchmark with the command `drnbench-request-response`, introduced" " by the Gem package [drnbench]().\n" -"It measures both response time and throughput of the target service." +"It measures both latency and throughput of the target service." msgstr "" "ベンチマークは、[drnbench]()というGemパッケージによって導入される`drnbench-request-response`コマンドで行うことがで" "きます。\n" -"このツールは、計測対象のサービスについて応答時間とスループットの両方を計測できます。" +"このツールは、計測対象のサービスについてレイテンシーとスループットの両方を計測できます。" msgid "### How the benchmark tool measures the performance?" msgstr "### ベンチマークツールはどのように性能を測定するのか" @@ -213,48 +213,47 @@ 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" +"Latency is easily analyzed - the smaller is the better.\n" +"The minimum and average elapsed time becomes small if any cache system is work" +"ing 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," +"ected errors, and so on." msgstr "" -"経過時間（応答時間）は簡単に分析できます。値が小さければ小さいほどよいと言えます。\n" +"レイテンシーは簡単に分析できます。値が小さければ小さいほどよいと言えます。\n" "対象サービスのキャッシュ機構が正常に動作している場合、最小と平均の応答時間は小さくなります。\n" "最大応答時間は、重たいクエリ、システムのメモリのスワップの発生、意図しないエラーの発生などの影響を受けます。" msgid "" -"See also the last two columns, `0` and `200`.\n" -"They mean the percentage of HTTP response statuses.\n" +"See the last columns named `200`.\n" +"It means the percentage of HTTP response statuses.\n" "`200` is \"OK\", `0` is \"timed out\".\n" "If clients got `400`, `500` and other errors, they will be also reported.\n" -"These information will help you to detect unexpected slow down.\n" -"(Because in-progress requests are shut down on the end of each case and they a" -"re reported as \"timed out\", `200` is not 100% in this result.)" +"These information will help you to detect unexpected slow down." msgstr "" -"最後の2つの列、`0`と`200`も見て下さい。\n" -"これらはHTTPレスポンスのステータスの割合を示しています。\n" +"最後の列、`200`を見て下さい。\n" +"これはHTTPレスポンスのステータスの割合を示しています。\n" "`200`は「OK」、`0`は「タイムアウト」です。\n" "`400`や`500`などのエラーレスポンスが得られた場合も、同様に報告されます。\n" -"これらの情報は、意図しない速度低下の原因究明に役立つでしょう。\n" -"（各段階の終了時に進行中だったリクエストが強制中断され、それらがタイムアウトとして報告されるため、この例では`200`は100%にはなっていません。）" +"これらの情報は、意図しない速度低下の原因究明に役立つでしょう。" msgid "To analyze throughput, a graph is useful." msgstr "スループットの分析には、グラフが便利です。" -msgid "" -msgstr "" +msgid "" +"![A graph of throughput](/images/tutorial/benchmark/throughput-groonga-1.0.8.p" +"ng)" +msgstr "" msgid "" -"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 " +"You'll see that the \"qps\" stagnated around 150, for 12 or more clients.\n" +"This means that the target service can process 150 requests in one second, at " "a maximum." msgstr "" -"12クライアントを超えたあたりで、qps値が250前後で頭打ちになっているのを見て取れるでしょう。\n" -"これは、計測対象のサービスが1秒あたり最大で250件のリクエストを処理できるということを意味しています。" +"12クライアントを超えたあたりで、qps値が150前後で頭打ちになっているのを見て取れるでしょう。\n" +"これは、計測対象のサービスが1秒あたり最大で150件のリクエストを処理できるということを意味しています。" msgid "" -"In other words, we can describe the result as: 250qps is the maximum throughpu" +"In other words, we can describe the result as: 150qps is the maximum throughpu" "t performance of this system - generic performance of hardware, software, netw" "ork, size of the database, queries, and more.\n" "If the number of requests for your service is growing up and it is going to re" @@ -262,7 +261,7 @@ msgid "" "he computer with more powerful one, and so on." msgstr "" "言い直すと、この結果は「（ハードウェア、ソフトウェア、ネットワーク、データベースの大きさ、クエリの内容など、様々な要素をひっくるめた）このシステムのスループ" -"ットの性能限界は250qpsである」という風に読み取ることができます。\n" +"ットの性能限界は150qpsである」という風に読み取ることができます。\n" "もしサービスに対するリクエストの件数が増加しつつあり、この限界に近づいているようであれば、クエリの最適化やコンピュータ自体のアップグレードなど、何らかの対策" "を取ることを検討する必要があると言えます。" @@ -1359,9 +1358,11 @@ msgid "For example, you can plot a graph from these results like:" msgstr "例えば、これらの結果は以下のようにグラフ化できます:" msgid "" -"![A layered graph of throughput](/images/tutorial/benchmark/throughput-mixed.p" -"ng)" -msgstr "" +"![A layered graph of throughput](/images/tutorial/benchmark/throughput-mixed-1" +".0.8.png)" +msgstr "" +"![それぞれの場合のスループットを重ねたグラフ](/images/tutorial/benchmark/throughput-mixed-1.0.8.png" +")" msgid "" "You can explain this graph as: \"On this condition Droonga has better performan" Modified: ja/tutorial/1.0.8/benchmark/index.md (+45 -27) =================================================================== --- ja/tutorial/1.0.8/benchmark/index.md 2014-11-28 17:44:11 +0900 (376b800) +++ ja/tutorial/1.0.8/benchmark/index.md 2014-11-29 00:33:33 +0900 (fab7eba) @@ -43,13 +43,13 @@ DroongaはGroongaと互換性があるため、Groongaベースのアプリケ あるシステムの性能を表す指標としては、以下の2つが多く使われます。 - * 応答時間 + * レイテンシー * スループット -応答時間とは、システムがリクエストを受け取ってからレスポンスを返すまでに実際にかかった時間のことです。 +レイテンシーとは、システムがリクエストを受け取ってからレスポンスを返すまでに実際にかかった応答時間のことです。 言い換えると、これは各リクエストについてクライアントが待たされた時間です。 この指標においては、数値は小さければ小さいほどよいです。 -一般的に、クエリが軽い場合や、データベースのサイズが小さい場合、クライアント数が少ない場合に、応答時間は短くなります。 +一般的に、クエリが軽い場合や、データベースのサイズが小さい場合、クライアント数が少ない場合に、レイテンシーは小さくなります。 スループットは、一度にどれだけの数のリクエストを捌けるかを意味するものです。 性能の指標は「*クエリ毎秒*（Queries Per Second, *qps*）」という単位で表されます。 @@ -58,7 +58,7 @@ DroongaはGroongaと互換性があるため、Groongaベースのアプリケ ともかく、「10qps」という数値は、1秒が経過する間にそのGroongaサーバが実際に10件のリクエストを受け付けて、レスポンスを返したということを意味します。 ベンチマークは、[drnbench]()というGemパッケージによって導入される`drnbench-request-response`コマンドで行うことができます。 -このツールは、計測対象のサービスについて応答時間とスループットの両方を計測できます。 +このツールは、計測対象のサービスについてレイテンシーとスループットの両方を計測できます。 ### ベンチマークツールはどのように性能を測定するのか @@ -78,18 +78,18 @@ DroongaはGroongaと互換性があるため、Groongaベースのアプリケ 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 + n_clients,total_n_requests,queries_per_second,min_elapsed_time,max_elapsed_time,average_elapsed_time,200 + 1,996,33.2,0.001773766,0.238031643,0.019765581680722916,100.0 + 2,1973,65.76666666666667,0.001558398,0.272225481,0.020047345673086702,100.0 + 4,3559,118.63333333333334,0.001531184,0.39942581,0.023357554419499882,100.0 + 6,4540,151.33333333333334,0.001540704,0.501663069,0.042344890696916264,100.0 + 8,4247,141.56666666666666,0.001483995,0.577100609,0.045836844514480835,100.0 + 10,4466,148.86666666666667,0.001987089,0.604507078,0.06949704923846833,100.0 + 12,4500,150.0,0.001782343,0.612596799,0.06902839555222215,100.0 + 14,4183,139.43333333333334,0.001980711,0.60754769,0.1033681068718623,100.0 + 16,4519,150.63333333333333,0.00284654,0.653204575,0.09473386513387955,100.0 + 18,4362,145.4,0.002330049,0.640683693,0.12581190483929405,100.0 + 20,4228,140.93333333333334,0.003710795,0.662666076,0.1301649290901133,100.0 ~~~ この結果は、分析や、グラフ描画など、様々な使い方ができます。 @@ -101,25 +101,43 @@ DroongaはGroongaと互換性があるため、Groongaベースのアプリケ 上の例を見て下さい。 -経過時間（応答時間）は簡単に分析できます。値が小さければ小さいほどよいと言えます。 -対象サービスのキャッシュ機構が正常に動作している場合、最小と平均の応答時間は小さくなります。 -最大応答時間は、重たいクエリ、システムのメモリのスワップの発生、意図しないエラーの発生などの影響を受けます。 +#### HTTP response statuses -最後の2つの列、`0`と`200`も見て下さい。 -これらはHTTPレスポンスのステータスの割合を示しています。 +最後の列、`200`を見て下さい。 +これはHTTPレスポンスのステータスの割合を示しています。 `200`は「OK」、`0`は「タイムアウト」です。 `400`や`500`などのエラーレスポンスが得られた場合も、同様に報告されます。 これらの情報は、意図しない速度低下の原因究明に役立つでしょう。 -（各段階の終了時に進行中だったリクエストが強制中断され、それらがタイムアウトとして報告されるため、この例では`200`は100%にはなっていません。） + +#### Latency + +レイテンシーは簡単に分析できます。値が小さければ小さいほどよいと言えます。 +対象サービスのキャッシュ機構が正常に動作している場合、最小と平均の応答時間は小さくなります。 +最大応答時間は、重たいクエリ、システムのメモリのスワップの発生、意図しないエラーの発生などの影響を受けます。 + +A graph of latency also reveals the maximum number of effectively acceptable connections in same time. + + + +This is a graph of `average_elapsed_time`. +You'll see that the time is increased for over 4 clients. +What it means? + +Groonga can process multiple requests completely parallelly, until the number of available processors. +When the computer has 4 processors, the system can process 4 or less requests in same time, without extra latency. +And, if more requests are sent, 5th and later requests will be processed after a preceding request is processed. +The graph confirms that the logical limitation is true. + +#### Throughput スループットの分析には、グラフが便利です。 - + -12クライアントを超えたあたりで、qps値が250前後で頭打ちになっているのを見て取れるでしょう。 -これは、計測対象のサービスが1秒あたり最大で250件のリクエストを処理できるということを意味しています。 +12クライアントを超えたあたりで、qps値が150前後で頭打ちになっているのを見て取れるでしょう。 +これは、計測対象のサービスが1秒あたり最大で150件のリクエストを処理できるということを意味しています。 -言い直すと、この結果は「（ハードウェア、ソフトウェア、ネットワーク、データベースの大きさ、クエリの内容など、様々な要素をひっくるめた）このシステムのスループットの性能限界は250qpsである」という風に読み取ることができます。 +言い直すと、この結果は「（ハードウェア、ソフトウェア、ネットワーク、データベースの大きさ、クエリの内容など、様々な要素をひっくるめた）このシステムのスループットの性能限界は150qpsである」という風に読み取ることができます。 もしサービスに対するリクエストの件数が増加しつつあり、この限界に近づいているようであれば、クエリの最適化やコンピュータ自体のアップグレードなど、何らかの対策を取ることを検討する必要があると言えます。 また、同じリクエストのパターンをGroongaとDroongaに送ることで、各システムの応答時間とqps値の上限（性能限界）を比較することができます。 @@ -756,7 +774,7 @@ Droongaクラスタの性能を有効に測定するためには、各ノード 例えば、これらの結果は以下のようにグラフ化できます: - + このグラフは、「この条件下では、Droongaは複数ノードであれば良い性能が出ている」「この設定だと、1ノード構成ではDroongaの性能はGroongaに及ばない」などのように読み取ることができます。 Modified: tutorial/1.0.8/benchmark/index.md (+45 -27) =================================================================== --- tutorial/1.0.8/benchmark/index.md 2014-11-28 17:44:11 +0900 (dd8b4ea) +++ tutorial/1.0.8/benchmark/index.md 2014-11-29 00:33:33 +0900 (a9ac6ce) @@ -34,13 +34,13 @@ Benchmarking will make it clear. There are two major indexes to indicate performance of a system. - * response time + * latency * throughput -Response time is the actual elapsed time between two moments: when the system receives a request, and when it returns a response. +Latency is the response time, actual elapsed time between two moments: when the system receives a request, and when it returns a response. In other words, for clients, it is the time to wait for each request. At this index, the smaller is the better. -In general, response time becomes small for lightweight queries, small size database, or less clients. +In general, latency becomes small for lightweight queries, small size database, or less clients. Throughput means how many request can be processed in a time. The performance index is described as "*queries per second* (*qps*)". @@ -49,7 +49,7 @@ Possibly there are 10 users (clients), or, there are 2 users and each user opens Anyway, "10qps" means that the Groonga actually accepted and responded for 10 requests while one second is passing. You can run benchmark with the command `drnbench-request-response`, introduced by the Gem package [drnbench](). -It measures both response time and throughput of the target service. +It measures both latency and throughput of the target service. ### How the benchmark tool measures the performance? @@ -69,18 +69,18 @@ It measures both response time and throughput of the target service. 6. Finally, the master process reports minimum/maximum/average elapsed time, "qps", and other extra information for each case, as a CSV file like: ~~~ - 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 + n_clients,total_n_requests,queries_per_second,min_elapsed_time,max_elapsed_time,average_elapsed_time,200 + 1,996,33.2,0.001773766,0.238031643,0.019765581680722916,100.0 + 2,1973,65.76666666666667,0.001558398,0.272225481,0.020047345673086702,100.0 + 4,3559,118.63333333333334,0.001531184,0.39942581,0.023357554419499882,100.0 + 6,4540,151.33333333333334,0.001540704,0.501663069,0.042344890696916264,100.0 + 8,4247,141.56666666666666,0.001483995,0.577100609,0.045836844514480835,100.0 + 10,4466,148.86666666666667,0.001987089,0.604507078,0.06949704923846833,100.0 + 12,4500,150.0,0.001782343,0.612596799,0.06902839555222215,100.0 + 14,4183,139.43333333333334,0.001980711,0.60754769,0.1033681068718623,100.0 + 16,4519,150.63333333333333,0.00284654,0.653204575,0.09473386513387955,100.0 + 18,4362,145.4,0.002330049,0.640683693,0.12581190483929405,100.0 + 20,4228,140.93333333333334,0.003710795,0.662666076,0.1301649290901133,100.0 ~~~ You can analyze it, draw a graph from it, and so on. @@ -92,25 +92,43 @@ It measures both response time and throughput of the target service. 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, +#### HTTP response statuses -See also the last two columns, `0` and `200`. -They mean the percentage of HTTP response statuses. +See the last columns named `200`. +It means the percentage of HTTP response statuses. `200` is "OK", `0` is "timed out". If clients got `400`, `500` and other errors, they will be also reported. These information will help you to detect unexpected slow down. -(Because in-progress requests are shut down on the end of each case and they are reported as "timed out", `200` is not 100% in this result.) + +#### Latency + +Latency is easily analyzed - the smaller is the better. +The minimum and average elapsed 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. + +A graph of latency also reveals the maximum number of effectively acceptable connections in same time. + + + +This is a graph of `average_elapsed_time`. +You'll see that the time is increased for over 4 clients. +What it means? + +Groonga can process multiple requests completely parallelly, until the number of available processors. +When the computer has 4 processors, the system can process 4 or less requests in same time, without extra latency. +And, if more requests are sent, 5th and later requests will be processed after a preceding request is processed. +The graph confirms that the logical limitation is true. + +#### Throughput To analyze throughput, a graph is useful. - + -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. +You'll see that the "qps" stagnated around 150, for 12 or more clients. +This means that the target service can process 150 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. +In other words, we can describe the result as: 150qps 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 response times and maximum "qps" for each system. @@ -748,7 +766,7 @@ OK, now you have four results: For example, you can plot a graph from these results like: - + You can explain this graph as: "On this condition Droonga has better performance when there are multiple nodes", "Single Droonga node's performance is lesser than Groonga's one, on this setting", and so on. -------------- next part -------------- HTML����������������������������...Download
