SHIMODA Piro Hiroshi
null+****@clear*****
Sat Oct 4 03:05:32 JST 2014
SHIMODA "Piro" Hiroshi 2014-10-04 03:05:32 +0900 (Sat, 04 Oct 2014) New Revision: 36c3543f62c0b3f13518b4cebb12942d295d1820 https://github.com/droonga/droonga.org/commit/36c3543f62c0b3f13518b4cebb12942d295d1820 Message: Write "qps" in lower case 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 (+23 -19) =================================================================== --- _po/ja/tutorial/1.0.7/benchmark/index.po 2014-10-04 02:59:00 +0900 (b97293d) +++ _po/ja/tutorial/1.0.7/benchmark/index.po 2014-10-04 03:05:32 +0900 (2a87855) @@ -37,7 +37,7 @@ msgstr "## チュートリアルのゴール" msgid "" "Learning steps to benchmark a [Droonga][] cluster and compare it to a [Groonga" "][groonga] server." -msgstr "[Droonga][]クラスタのベンチマークの測定し、[Groonga][groonga]での結果と比較するまでの、一連の手順を学ぶこと。" +msgstr "[Droonga][]クラスタのベンチマークを測定し、[Groonga][groonga]での結果と比較するまでの、一連の手順を学ぶこと。" msgid "## Precondition" msgstr "## 前提条件" @@ -98,21 +98,25 @@ msgid "" " by the Gem package [drnbench]().\n" "It measures the throughput performance of the target service - how many reques" "t can be processed in a time.\n" -"The performance index is described as \"*queries per second* (*QPS*)\"." +"The performance index is described as \"*queries per second* (*qps*)\"." msgstr "" "ベンチマークは、[drnbench]()というGemパッケージによって導入される`drnbench-request-response`コマンドで行うことがで" "きます。\n" "このツールは、対象サービスのスループット性能、つまり、一度にどれだけの数のリクエストを捌けるかを計測します。\n" -"性能の指標は「*クエリ毎秒*（Queries Per Second, *QPS*）」という単位で表されます。" +"性能の指標は「*クエリ毎秒*（Queries Per Second, *qps*）」という単位で表されます。" msgid "" "For example, if a Groonga server processed 10 requests in one second, that is " -"described as \"10 QPS\".\n" +"described as \"10qps\".\n" "Possibly there are 10 users (clients), or, there are 2 users and each user ope" "ns 5 tabs in his web browser.\n" -"Anyway, \"10 QPS\" means that the Groonga actually accepted and responded for 10" -" requests while one second is passing." +"Anyway, \"10qps\" means that the Groonga actually accepted and responded for 10 " +"requests while one second is passing." msgstr "" +"例えば、あるGroongaサーバが1秒に10件のリクエストを処理できたとき、これを「10qps」と表現します。\n" +"10人のユーザ（クライアント）がいるのかもしれませんし、2人のユーザがそれぞれブラウザ上で5つのタブを開いているのかもしれません。\n" +"ともかく、「10qps」という数値は、1秒が経過する間にそのGroongaサーバが実際に10件のリクエストを受け付けて、レスポンスを返したということを意味し" +"ます。" msgid "" "`drnbench-request-response` benchmarks the target service, by steps like follo" @@ -125,15 +129,15 @@ msgid "" "quently.\n" " 2. After a while, the master process kills the client.\n" " Then he counts up the number of requests actually processed by the target," -" and reports it as QPS of the single client case.\n" +" and reports it as \"qps\" of the single client case.\n" " 3. The master process generates two virtual clients.\n" " They starts to send requests.\n" " 4. After a while, the master process kills all clients.\n" " Then total number of processed requests sent by all clients is reported as" -" QPS of the two clients case.\n" +" \"qps\" of the two clients case.\n" " 5. Repeated with three clients, four clients ... and more progressively.\n" -" 6. Finally, the master process reports QPS and other extra information for ea" -"ch case, as a CSV file like:" +" 6. Finally, the master process reports \"qps\" and other extra information for " +"each case, as a CSV file like:" msgstr "" msgid "" @@ -181,15 +185,15 @@ 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" +"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 "" msgid "" -"In other words, we can describe the result as: 250 QPS is the maximum throughp" -"ut performance of this system - generic performance of hardware, software, net" -"work, size of the database, queries, and more.\n" +"In other words, we can describe the result as: 250qps 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" "ach the limit, you have to do something about it - optimize queries, replace t" "he computer with more powerful one, and so on." @@ -197,10 +201,10 @@ msgstr "" msgid "" "And, sending same request patterns to Groonga and Droonga, you can compare max" -"imum QPS for each system.\n" -"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 Gr" -"oogna to Droonga.\n" +"imum \"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 "" @@ -912,7 +916,7 @@ msgid "" msgstr "" msgid "## Conclusion" -msgstr "" +msgstr "## まとめ" msgid "" "In this tutorial, you did prepare a reference [Groonga][] server and [Droonga]" Modified: ja/tutorial/1.0.7/benchmark/index.md (+12 -12) =================================================================== --- ja/tutorial/1.0.7/benchmark/index.md 2014-10-04 02:59:00 +0900 (721b9a5) +++ ja/tutorial/1.0.7/benchmark/index.md 2014-10-04 03:05:32 +0900 (3631f51) @@ -21,7 +21,7 @@ this is based on https://github.com/droonga/presentation-droonga-meetup-1-introd ## チュートリアルのゴール -[Droonga][]クラスタのベンチマークの測定し、[Groonga][groonga]での結果と比較するまでの、一連の手順を学ぶこと。 +[Droonga][]クラスタのベンチマークを測定し、[Groonga][groonga]での結果と比較するまでの、一連の手順を学ぶこと。 ## 前提条件 @@ -52,24 +52,24 @@ DroongaはGroongaと互換性があるため、Groongaベースのアプリケ ベンチマークは、[drnbench]()というGemパッケージによって導入される`drnbench-request-response`コマンドで行うことができます。 このツールは、対象サービスのスループット性能、つまり、一度にどれだけの数のリクエストを捌けるかを計測します。 -性能の指標は「*クエリ毎秒*（Queries Per Second, *QPS*）」という単位で表されます。 +性能の指標は「*クエリ毎秒*（Queries Per Second, *qps*）」という単位で表されます。 -For example, if a Groonga server processed 10 requests in one second, that is described as "10 QPS". -Possibly there are 10 users (clients), or, there are 2 users and each user opens 5 tabs in his web browser. -Anyway, "10 QPS" means that the Groonga actually accepted and responded for 10 requests while one second is passing. +例えば、あるGroongaサーバが1秒に10件のリクエストを処理できたとき、これを「10qps」と表現します。 +10人のユーザ（クライアント）がいるのかもしれませんし、2人のユーザがそれぞれブラウザ上で5つのタブを開いているのかもしれません。 +ともかく、「10qps」という数値は、1秒が経過する間にそのGroongaサーバが実際に10件のリクエストを受け付けて、レスポンスを返したということを意味します。 `drnbench-request-response` benchmarks the target service, by steps like following: 1. The master process generates one virtual client. The client starts to send many requests to the target sequentially and frequently. 2. After a while, the master process kills the client. - Then he counts up the number of requests actually processed by the target, and reports it as QPS of the single client case. + Then he counts up the number of requests actually processed by the target, and reports it as "qps" of the single client case. 3. The master process generates two virtual clients. They starts to send requests. 4. After a while, the master process kills all clients. - Then total number of processed requests sent by all clients is reported as QPS of the two clients case. + Then total number of processed requests sent by all clients is reported as "qps" of the two clients case. 5. Repeated with three clients, four clients ... and more progressively. - 6. Finally, the master process reports QPS and other extra information for each case, as a CSV file like: + 6. Finally, the master process reports "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 @@ -96,14 +96,14 @@ Anyway, "10 QPS" means that the Groonga actually accepted and responded for 10 r  Look at the result above, and this graph. -You'll see that the QPS stagnated around 250, for 12 or more clients. +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: 250 QPS 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: 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. -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. +And, sending same request patterns to Groonga and Droonga, you can compare 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. Modified: tutorial/1.0.7/benchmark/index.md (+10 -10) =================================================================== --- tutorial/1.0.7/benchmark/index.md 2014-10-04 02:59:00 +0900 (07881a5) +++ tutorial/1.0.7/benchmark/index.md 2014-10-04 03:05:32 +0900 (57af3cc) @@ -43,24 +43,24 @@ Benchmarking will make it clear. You can run benchmark with the command `drnbench-request-response`, introduced by the Gem package [drnbench](). It measures the throughput performance of the target service - how many request can be processed in a time. -The performance index is described as "*queries per second* (*QPS*)". +The performance index is described as "*queries per second* (*qps*)". -For example, if a Groonga server processed 10 requests in one second, that is described as "10 QPS". +For example, if a Groonga server processed 10 requests in one second, that is described as "10qps". Possibly there are 10 users (clients), or, there are 2 users and each user opens 5 tabs in his web browser. -Anyway, "10 QPS" means that the Groonga actually accepted and responded for 10 requests while one second is passing. +Anyway, "10qps" means that the Groonga actually accepted and responded for 10 requests while one second is passing. `drnbench-request-response` benchmarks the target service, by steps like following: 1. The master process generates one virtual client. The client starts to send many requests to the target sequentially and frequently. 2. After a while, the master process kills the client. - Then he counts up the number of requests actually processed by the target, and reports it as QPS of the single client case. + Then he counts up the number of requests actually processed by the target, and reports it as "qps" of the single client case. 3. The master process generates two virtual clients. They starts to send requests. 4. After a while, the master process kills all clients. - Then total number of processed requests sent by all clients is reported as QPS of the two clients case. + Then total number of processed requests sent by all clients is reported as "qps" of the two clients case. 5. Repeated with three clients, four clients ... and more progressively. - 6. Finally, the master process reports QPS and other extra information for each case, as a CSV file like: + 6. Finally, the master process reports "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 @@ -87,14 +87,14 @@ Anyway, "10 QPS" means that the Groonga actually accepted and responded for 10 r  Look at the result above, and this graph. -You'll see that the QPS stagnated around 250, for 12 or more clients. +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: 250 QPS 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: 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. -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. +And, sending same request patterns to Groonga and Droonga, you can compare 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. -------------- next part -------------- HTML����������������������������...Download