YUKI Hiroshi
null+****@clear*****
Sat Nov 29 00:44:13 JST 2014
YUKI Hiroshi 2014-11-29 00:44:13 +0900 (Sat, 29 Nov 2014) New Revision: aec9cfaf70376d6ba9175d126f21b734c5dd7436 https://github.com/droonga/droonga.org/commit/aec9cfaf70376d6ba9175d126f21b734c5dd7436 Message: Translate description of latency 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 (+71 -34) =================================================================== --- _po/ja/tutorial/1.0.8/benchmark/index.po 2014-11-29 00:33:33 +0900 (0eb8542) +++ _po/ja/tutorial/1.0.8/benchmark/index.po 2014-11-29 00:44:13 +0900 (4624dda) @@ -170,29 +170,26 @@ msgstr "" msgid "" " ~~~\n" " n_clients,total_n_requests,queries_per_second,min_elapsed_time,max_elapsed" -"_time,average_elapsed_time,0,200\n" -" 1,164,5.466666666666667,0.002184631,1.951960432,0.1727086823963415,0,100.0" +"_time,average_elapsed_time,200\n" +" 1,996,33.2,0.001773766,0.238031643,0.019765581680722916,100.0\n" +" 2,1973,65.76666666666667,0.001558398,0.272225481,0.020047345673086702,100." +"0\n" +" 4,3559,118.63333333333334,0.001531184,0.39942581,0.023357554419499882,100." +"0\n" +" 6,4540,151.33333333333334,0.001540704,0.501663069,0.042344890696916264,100" +".0\n" +" 8,4247,141.56666666666666,0.001483995,0.577100609,0.045836844514480835,100" +".0\n" +" 10,4466,148.86666666666667,0.001987089,0.604507078,0.06949704923846833,100" +".0\n" +" 12,4500,150.0,0.001782343,0.612596799,0.06902839555222215,100.0\n" +" 14,4183,139.43333333333334,0.001980711,0.60754769,0.1033681068718623,100.0" "\n" -" 2,1618,53.93333333333333,0.001466091,1.587372312,0.026789948272558754,0.12" -"360939431396785,99.87639060568603\n" -" 4,4690,156.33333333333334,0.001065161,0.26070575,0.015224578191897657,0.04" -"2643923240938165,99.95735607675907\n" -" 6,6287,209.56666666666666,0.000923332,0.25709169,0.018191428254970568,0.09" -"543502465404805,99.90456497534595\n" -" 8,6628,220.93333333333334,0.000979707,0.288406006,0.02557014875603507,0.03" -"0175015087507546,99.96982498491249\n" -" 10,7117,237.23333333333332,0.001235846,0.303093461,0.03160425060474918,0.1" -"405086412814388,99.85949135871857\n" -" 12,7403,246.76666666666668,0.001111115,0.33163911,0.03792291040199917,0.09" -"455626097528029,99.90544373902472\n" -" 14,7454,248.46666666666667,0.00151987,0.335161281,0.04522922885028168,0.17" -"4403005097934,99.82559699490207\n" -" 16,7357,245.23333333333332,0.000763487,0.356862003,0.05435767224085904,0.0" -"8155498165012913,99.91844501834987\n" -" 18,7494,249.8,0.001017168,0.378661333,0.061178927504003194,0.2001601281024" -"8196,99.79983987189752\n" -" 20,7506,250.2,0.001759464,0.404634447,0.06887332192845741,0.21316280309086" -"064,99.78683719690913\n" +" 16,4519,150.63333333333333,0.00284654,0.653204575,0.09473386513387955,100." +"0\n" +" 18,4362,145.4,0.002330049,0.640683693,0.12581190483929405,100.0\n" +" 20,4228,140.93333333333334,0.003710795,0.662666076,0.1301649290901133,100." +"0\n" " ~~~" msgstr "" @@ -212,16 +209,8 @@ msgstr "### 結果の読み方と分析の仕方 {#how-to-analyze}" msgid "Look at the result above." msgstr "上の例を見て下さい。" -msgid "" -"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." -msgstr "" -"レイテンシーは簡単に分析できます。値が小さければ小さいほどよいと言えます。\n" -"対象サービスのキャッシュ機構が正常に動作している場合、最小と平均の応答時間は小さくなります。\n" -"最大応答時間は、重たいクエリ、システムのメモリのスワップの発生、意図しないエラーの発生などの影響を受けます。" +msgid "#### HTTP response statuses" +msgstr "#### HTTPレスポンスのステータス" msgid "" "See the last columns named `200`.\n" @@ -236,8 +225,56 @@ msgstr "" "`400`や`500`などのエラーレスポンスが得られた場合も、同様に報告されます。\n" "これらの情報は、意図しない速度低下の原因究明に役立つでしょう。" -msgid "To analyze throughput, a graph is useful." -msgstr "スループットの分析には、グラフが便利です。" +msgid "#### Latency" +msgstr "#### レイテンシー" + +msgid "" +"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." +msgstr "" +"レイテンシーは簡単に分析できます。値が小さければ小さいほどよいと言えます。\n" +"対象サービスのキャッシュ機構が正常に動作している場合、最小と平均の応答時間は小さくなります。\n" +"最大応答時間は、重たいクエリ、システムのメモリのスワップの発生、意図しないエラーの発生などの影響を受けます。" + +msgid "" +"A graph of latency also reveals the maximum number of effectively acceptable c" +"onnections in same time." +msgstr "レイテンシーのグラフは、有用な同時接続数の上限も明らかにします。" + +msgid "" +msgstr "" + +msgid "" +"This is a graph of `average_elapsed_time`.\n" +"You'll see that the time is increased for over 4 clients.\n" +"What it means?" +msgstr "" +"これは`average_elapsed_time`のグラフです。\n" +"4クライアントを越えた所で経過時間が増加していることが見て取れるでしょう。\n" +"これは何を意味するのでしょうか？" + +msgid "" +"Groonga can process multiple requests completely parallelly, until the number " +"of available processors.\n" +"When the computer has 4 processors, the system can process 4 or less requests " +"in same time, without extra latency.\n" +"And, if more requests are sent, 5th and later requests will be processed after" +" a preceding request is processed.\n" +"The graph confirms that the logical limitation is true." +msgstr "" +"Groongaは利用可能なプロセッサ数と同じ数だけのリクエストを完全に並行処理できます。\n" +"コンピュータのプロセッサ数が4である場合、そのシステムは4件以下のリクエストについては余計な待ち時間無しで同時に処理することができます。\n" +"それ以上の数のリクエストが来た場合、5番目以降のリクエストは、それ以前に受け付けたリクエストの処理完了後に処理されます。\n" +"先のグラフは、この理論上の上限が事実であることを示しています。" + +msgid "#### Throughput" +msgstr "#### スループット" + +msgid "A graph helps you to analyze throughput performance." +msgstr "スループット性能の分析にも、グラフが便利です。" msgid "" "![A graph of throughput](/images/tutorial/benchmark/throughput-groonga-1.0.8.p" Modified: ja/tutorial/1.0.8/benchmark/index.md (+13 -13) =================================================================== --- ja/tutorial/1.0.8/benchmark/index.md 2014-11-29 00:33:33 +0900 (fab7eba) +++ ja/tutorial/1.0.8/benchmark/index.md 2014-11-29 00:44:13 +0900 (1a09f88) @@ -101,7 +101,7 @@ DroongaはGroongaと互換性があるため、Groongaベースのアプリケ 上の例を見て下さい。 -#### HTTP response statuses +#### HTTPレスポンスのステータス 最後の列、`200`を見て下さい。 これはHTTPレスポンスのステータスの割合を示しています。 @@ -109,28 +109,28 @@ DroongaはGroongaと互換性があるため、Groongaベースのアプリケ `400`や`500`などのエラーレスポンスが得られた場合も、同様に報告されます。 これらの情報は、意図しない速度低下の原因究明に役立つでしょう。 -#### 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? +これは`average_elapsed_time`のグラフです。 +4クライアントを越えた所で経過時間が増加していることが見て取れるでしょう。 +これは何を意味するのでしょうか？ -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. +Groongaは利用可能なプロセッサ数と同じ数だけのリクエストを完全に並行処理できます。 +コンピュータのプロセッサ数が4である場合、そのシステムは4件以下のリクエストについては余計な待ち時間無しで同時に処理することができます。 +それ以上の数のリクエストが来た場合、5番目以降のリクエストは、それ以前に受け付けたリクエストの処理完了後に処理されます。 +先のグラフは、この理論上の上限が事実であることを示しています。 -#### Throughput +#### スループット -スループットの分析には、グラフが便利です。 +スループット性能の分析にも、グラフが便利です。  Modified: tutorial/1.0.8/benchmark/index.md (+1 -1) =================================================================== --- tutorial/1.0.8/benchmark/index.md 2014-11-29 00:33:33 +0900 (a9ac6ce) +++ tutorial/1.0.8/benchmark/index.md 2014-11-29 00:44:13 +0900 (e052ea7) @@ -121,7 +121,7 @@ The graph confirms that the logical limitation is true. #### Throughput -To analyze throughput, a graph is useful. +A graph helps you to analyze throughput performance.  -------------- next part -------------- HTML����������������������������...下載
