bananan_wの日記： 英語勉強日記#10(翻訳がんばろう日記)
日記 by
bananan_w
16章。どんどん行きましょう。
16.7以下はBeanShellに関することなので翻訳はパス。気が向いたら…
16. Best Practices
16. 成功事例
16.1 Limit the Number of Threads
16.1 スレッド数の制限値
Your hardware's capabilities will limit the number of threads you can effectively run with JMeter. It will also depend on how fast your server is (a faster server gives makes JMeter work harder since it returns request quicker). The more JMeter works, the less accurate its timing information will be. The more work JMeter does, the more each thread has to wait to get access to the CPU, the more inflated the timing information gets. If you need large-scale load testing, consider running multiple non-GUI JMeter instances on multiple machines.
ハードウェアの性能がJMeterで動作させることのできるスレッド数を制限します。これはサーバが高速に処理を行うこととは独立しています(高性能なサーバが高速に応答することによりJMeterはより多くの仕事を行いますが)。JMeterはより多くの仕事を行うと、時間情報は不正確になります。JMeterは更に多くの仕事を行うと、それぞれのスレッドがCPUを使用するために待機させられ、時間情報の取得に膨大な時間がかかるでしょう。巨大な負荷テストを必要とする場合には、複数のnon-GUI JMeterインスタンスを複数のマシンから実行することを検討してください。
16.2 Where to Put the Cookie Manager
16.2 クッキーマネージャをどこに設置するか
See Building a Web Test for information.
ウェブテスト計画の構築(訳注:Aタグ注意)を参照してください。
16.3 Where to Put the Authorization Manager
16.3 認証マネージャをどこに設置するか
See Building an Advanced Web Test for information.
高度なテスト計画の構築(訳注:Aタグ注意)を参照してください。
16.4 Using the Proxy Server
16.4 プロキシサーバを使用する
Refer to HTTP Proxy Server for details on setting up the proxy server. The most important thing to do is filter out all requests you aren't interested in. For instance, there's no point in recording image requests (JMeter can be instructed to download all images on a page - see HTTP Request ). These will just clutter your test plan. Most likely, there is an extension all your files share, such as .jsp, .asp, .php, .html or the like. These you should "include" by entering ".*\.jsp" as an "Include Pattern".
HTTPプロキシサーバ(訳注:Aタグ注意)を参照しプロキシサーバの設定の詳細を確認してください。最も重要なことは興味のないリクエストを全て除去することです。実例として、画像のリクエストを記録することは重要ではありません(JMeterはページ上の全ての画像をダウンロードするように手引きされます - HTTPリクエスト(訳注:Aタグ注意)を参照してください)。これらはテスト計画において無価値なものです。ほとんどの場合、重要なファイルが持つ拡張子は.jsp、.asp、.php、.html等です。これらは"Include Pattern"で".*\.jsp"として"include"に入力しておくべきです。
Alternatively, you can exclude images by entering ".*\.gif" as an "Exclude Pattern". Depending on your application, this may or may not be a better way to go. You may also have to exclude stylesheets, javascript files, and other included files. Test out your settings to verify you are recording what you want, and then erase and start fresh.
その他の方法として、画像ファイルを除外するために"Exclude Pattern"に".*\.gif"を入力します。良い方法かどうかは分かりませんがアプリケーションから独立しています。スタイルシート、javaスクリプトファイル、その他のincludeされたファイルを除外した方が好ましいです。望んでいるものが記録できているか検証して設定を確認後に、初期化して削除を行ってから開始させます。
The Proxy Server expects to find a ThreadGroup element with a Recording Controller under it where it will record HTTP Requests to. This conveniently packages all your samples under one controller, which can be given a name that describes the test case.
プロキシサーバはスレッドグループ要素が存在することを予期しており、レコーディングコントローラの下に存在し、記録するHTTPリクエストを送信します。好都合なことに全てのサンプルが一つのコントローラの下に一括して存在し、test caseについて説明する名前が付けられています。
Now, go through the steps of a Test Case. If you have no pre-defined test cases, use JMeter to record your actions to define your test cases. Once you have finished a definite series of steps, save the entire test case in an appropriately named file. Then, wipe clean and start a new test case. By doing this, you can quickly record a large number of test case "rough drafts".
Test Caseの手順を実行します。事前に定義したtest caseが存在しない場合には、JMeterはtest caseを定義するためにあなたの操作を記録します。手順の定義が完了したなら、完全なtest caseを適切なファイル名で保存します。そして新しいtest caseをもう一度はじめから開始します。実施にあたって、多数のtest caseの"素案"を用いて手早く行うことができます。
One of the most useful features of the Proxy Server is that you can abstract out certain common elements from the recorded samples. By defining some user-defined variables at the Test Plan level or in User Defined Variables elements, you can have JMeter automatically replace values in you recorded samples. For instance, if you are testing an app on server "xxx.example.com", then you can define a variable called "server" with the value of "xxx.example.com", and anyplace that value is found in your recorded samples will be replaced with "${server}".
プロキシサーバのもっとも便利な機能の一つは、記録されたサンプルからいくつかの共通要素を出力することです。テスト計画レベルからユーザ定義変数要素にいくつかのユーザ定義変数を定義し、記録したサンプルを元にJMeterが自動的に値を変更したものを得られます。例として、サーバ"xxx.example.com"上でアプリケーションのテストを行う際に、"server変数を定義して値を"xxx.example.com"とし、その値は記録されたサンプルのどこにでも存在し"${server}"で置換されているでしょう。
Please note that matching is case-sensitive.
マッチングに関しては場合によりけりであることに注意してください。
16.5 User variables
16.5 ユーザ変数
Some test plans need to use different values for different users/threads. For example, you might want to test a sequence that requires a unique login for each user. This is easy to achieve with the facilities provided by JMeter.
いくつかのテスト計画で異なるユーザやスレッドにおいて異なる値が必要となります。れいとして、それぞれのユーザに対して一意の連続的なログインを行うテストを実施すると仮定します。これはJMeterによる利便性によって簡単に実現できます。
For example:
例:
* Create a text file containing the user names and passwords, separated by commas. Put this in the same directory as your test plan.
* Add a CSV DataSet configuration element to the test plan. Name the variables USER and PASS.
* Replace the login name with ${USER} and the password with ${PASS} on the appropriate samplers
* ユーザ名とパスワードを含むカンマ区切のテキストファイルを作成します。これをテスト計画と同じディレクトリに設置します。
* CSVデータ設定要素をテスト計画に追加します。変数に USER と PASS と命名します。
* 適切なサンプラのログイン名を ${USER}、パスワードを ${PASS} に置換します。
The CSV Data Set element will read a new line for each thread.
CSVデータ設定要素はそれぞれのスレッドにおいて新しい行を読み込みます。
16.6 Reducing resource requirements
16.6 リソースの要求を軽減する
Some suggestions on reducing resource usage.
リソース消費量を軽減するいくつかの提案があります。
* Use non-GUI mode: jmeter -n -t test.jmx -l test.jtl
* non-GUIモードを使用する: jmeter -n -t test.jmx -l test.jtl
* Use as few Listeners as possible; if using the -l flag as above they can all be deleted or disabled.
* 可能な限りリスナの数を減らす。-lフラグを上記で使用する場合には全てを削除するか無効にします。
* Rather than using lots of similar samplers, use the same sampler in a loop, and use variables (CSV Data Set) to vary the sample. Or perhaps use the Access Log Sampler. [The Include Controller does not help here, as it adds all the test elements in the file to the test plan.]
* 沢山のサンプラを使用するのではなく、同じサンプラによるループと変数(CSVデータ設定要素)によってサンプルを変更させるべきです。もしくはアクセスログサンプラを使用してください。[テスト計画のファイルに存在する全てのテスト要素を追加するような手助けを組み込みのコントローラは行いません。]
* Don't use functional mode
* functionalモードを使用しない。
* Use CSV output rather than XML
* XMLではなくCSV出力を使用する。
* Only save the data that you need
* 必要なデータだけを保存する。
* Use as few Assertions as possible
* できるだけ少ないアサーションを使用する。
16.7 BeanShell server
The BeanShell interpreter has a very useful feature - it can act as a server, which is accessible by telnet or http.
There is no security. Anyone who can connect to the port can issue any BeanShell commands. These can provide unrestricted access to the JMeter application and the host. Do not enable the server unless the ports are protected against access, e.g. by a firewall.
If you do wish to use the server, define the following in jmeter.properties:
beanshell.server.port=9000
beanshell.server.file=../extras/startup.bsh
In the above example, the server will be started, and will listen on ports 9000 and 9001. Port 9000 will be used for http access. Port 9001 will be used for telnet access. The startup.bsh file will be processed by the server, and can be used to define various functions and set up variables. The startup file defines methods for setting and printing JMeter and system properties. This is what you should see in the JMeter console:
Startup script running
Startup script completed
Httpd started on port: 9000
Sessiond started on port: 9001
As a practical example, assume you have a long-running JMeter test running in non-GUI mode, and you want to vary the throughput at various times during the test. The test-plan includes a Constant Throughput Timer which is defined in terms of a property, e.g. ${__P(throughput)}. The following BeanShell commands could be used to change the test:
printprop("throughput");
curr=Integer.decode(args[0]); // Start value
inc=Integer.decode(args[1]); // Increment
end=Integer.decode(args[2]); // Final value
secs=Integer.decode(args[3]); // Wait between changes
while(curr <= end){
setprop("throughput",curr.toString()); // Needs to be a string here
Thread.sleep(secs*1000);
curr += inc;
}
printprop("throughput");
The script can be stored in a file (throughput.bsh, say), and sent to the server using bshclient.jar. For example:
java -jar ../lib/bshclient.jar localhost 9000 throughput.bsh 70 5 100 60
16.8 BeanShell scripting
16.8.1 Overview
Each BeanShell test element has its own copy of the interpreter (for each thread). If the test element is repeatedly called, e.g. within a loop, then the interpreter is retained between invocations unless the "Reset bsh.Interpreter before each call" option is selected.
Some long-running tests may cause the interpreter to use lots of memory; if this is the case try using the reset option.
You can test BeanShell scripts outside JMeter by using the command-line interpreter:
$ java -cp bsh-xxx.jar[;other jars as needed] bsh.Interperter file.bsh [parameters]
or
$ java -cp bsh-xxx.jar bsh.Interperter
bsh% source("file.bsh");
bsh% exit(); // or use EOF key (e.g. ^Z or ^D)
16.8.2 Sharing Variables
Variables can be defined in startup (initialisation) scripts. These will be retained across invocations of the test element, unless the reset option is used.\
Scripts can also access JMeter variables using the get() and put() methods of the "vars" variable, for example: vars.get("HOST"); vars.put("MSG","Successful"); . The get() and put() methods only support variables with String values, but there are also getObject() and putObject() methods which can be used for arbitrary objects. JMeter variables are local to a thread, but can be used by all test elements (not just Beanshell).
If you need to share variables between threads, then JMeter properties can be used:
import org.apache.jmeter.util.JMeterUtils;
String value=JMeterUtils.getPropDefault("name","");
JMeterUtils.setProperty("name", "value");
The sample .bshrc files contain sample definitions of getprop() and setprop() methods.
Another possible method of sharing variables is to use the "bsh.shared" shared namespace. For example:
if (bsh.shared.myObj == void){
// not yet defined, so create it:
myObj=new AnyObject();
}
bsh.shared.myObj.process();
Rather than creating the object in the test element, it can be created in the startup file defined by the JMeter property "beanshell.init.file". This is only processed once.
16.7以下はBeanShellに関することなので翻訳はパス。気が向いたら…
16. Best Practices
16. 成功事例
16.1 Limit the Number of Threads
16.1 スレッド数の制限値
Your hardware's capabilities will limit the number of threads you can effectively run with JMeter. It will also depend on how fast your server is (a faster server gives makes JMeter work harder since it returns request quicker). The more JMeter works, the less accurate its timing information will be. The more work JMeter does, the more each thread has to wait to get access to the CPU, the more inflated the timing information gets. If you need large-scale load testing, consider running multiple non-GUI JMeter instances on multiple machines.
ハードウェアの性能がJMeterで動作させることのできるスレッド数を制限します。これはサーバが高速に処理を行うこととは独立しています(高性能なサーバが高速に応答することによりJMeterはより多くの仕事を行いますが)。JMeterはより多くの仕事を行うと、時間情報は不正確になります。JMeterは更に多くの仕事を行うと、それぞれのスレッドがCPUを使用するために待機させられ、時間情報の取得に膨大な時間がかかるでしょう。巨大な負荷テストを必要とする場合には、複数のnon-GUI JMeterインスタンスを複数のマシンから実行することを検討してください。
16.2 Where to Put the Cookie Manager
16.2 クッキーマネージャをどこに設置するか
See Building a Web Test for information.
ウェブテスト計画の構築(訳注:Aタグ注意)を参照してください。
16.3 Where to Put the Authorization Manager
16.3 認証マネージャをどこに設置するか
See Building an Advanced Web Test for information.
高度なテスト計画の構築(訳注:Aタグ注意)を参照してください。
16.4 Using the Proxy Server
16.4 プロキシサーバを使用する
Refer to HTTP Proxy Server for details on setting up the proxy server. The most important thing to do is filter out all requests you aren't interested in. For instance, there's no point in recording image requests (JMeter can be instructed to download all images on a page - see HTTP Request ). These will just clutter your test plan. Most likely, there is an extension all your files share, such as .jsp, .asp, .php, .html or the like. These you should "include" by entering ".*\.jsp" as an "Include Pattern".
HTTPプロキシサーバ(訳注:Aタグ注意)を参照しプロキシサーバの設定の詳細を確認してください。最も重要なことは興味のないリクエストを全て除去することです。実例として、画像のリクエストを記録することは重要ではありません(JMeterはページ上の全ての画像をダウンロードするように手引きされます - HTTPリクエスト(訳注:Aタグ注意)を参照してください)。これらはテスト計画において無価値なものです。ほとんどの場合、重要なファイルが持つ拡張子は.jsp、.asp、.php、.html等です。これらは"Include Pattern"で".*\.jsp"として"include"に入力しておくべきです。
Alternatively, you can exclude images by entering ".*\.gif" as an "Exclude Pattern". Depending on your application, this may or may not be a better way to go. You may also have to exclude stylesheets, javascript files, and other included files. Test out your settings to verify you are recording what you want, and then erase and start fresh.
その他の方法として、画像ファイルを除外するために"Exclude Pattern"に".*\.gif"を入力します。良い方法かどうかは分かりませんがアプリケーションから独立しています。スタイルシート、javaスクリプトファイル、その他のincludeされたファイルを除外した方が好ましいです。望んでいるものが記録できているか検証して設定を確認後に、初期化して削除を行ってから開始させます。
The Proxy Server expects to find a ThreadGroup element with a Recording Controller under it where it will record HTTP Requests to. This conveniently packages all your samples under one controller, which can be given a name that describes the test case.
プロキシサーバはスレッドグループ要素が存在することを予期しており、レコーディングコントローラの下に存在し、記録するHTTPリクエストを送信します。好都合なことに全てのサンプルが一つのコントローラの下に一括して存在し、test caseについて説明する名前が付けられています。
Now, go through the steps of a Test Case. If you have no pre-defined test cases, use JMeter to record your actions to define your test cases. Once you have finished a definite series of steps, save the entire test case in an appropriately named file. Then, wipe clean and start a new test case. By doing this, you can quickly record a large number of test case "rough drafts".
Test Caseの手順を実行します。事前に定義したtest caseが存在しない場合には、JMeterはtest caseを定義するためにあなたの操作を記録します。手順の定義が完了したなら、完全なtest caseを適切なファイル名で保存します。そして新しいtest caseをもう一度はじめから開始します。実施にあたって、多数のtest caseの"素案"を用いて手早く行うことができます。
One of the most useful features of the Proxy Server is that you can abstract out certain common elements from the recorded samples. By defining some user-defined variables at the Test Plan level or in User Defined Variables elements, you can have JMeter automatically replace values in you recorded samples. For instance, if you are testing an app on server "xxx.example.com", then you can define a variable called "server" with the value of "xxx.example.com", and anyplace that value is found in your recorded samples will be replaced with "${server}".
プロキシサーバのもっとも便利な機能の一つは、記録されたサンプルからいくつかの共通要素を出力することです。テスト計画レベルからユーザ定義変数要素にいくつかのユーザ定義変数を定義し、記録したサンプルを元にJMeterが自動的に値を変更したものを得られます。例として、サーバ"xxx.example.com"上でアプリケーションのテストを行う際に、"server変数を定義して値を"xxx.example.com"とし、その値は記録されたサンプルのどこにでも存在し"${server}"で置換されているでしょう。
Please note that matching is case-sensitive.
マッチングに関しては場合によりけりであることに注意してください。
16.5 User variables
16.5 ユーザ変数
Some test plans need to use different values for different users/threads. For example, you might want to test a sequence that requires a unique login for each user. This is easy to achieve with the facilities provided by JMeter.
いくつかのテスト計画で異なるユーザやスレッドにおいて異なる値が必要となります。れいとして、それぞれのユーザに対して一意の連続的なログインを行うテストを実施すると仮定します。これはJMeterによる利便性によって簡単に実現できます。
For example:
例:
* Create a text file containing the user names and passwords, separated by commas. Put this in the same directory as your test plan.
* Add a CSV DataSet configuration element to the test plan. Name the variables USER and PASS.
* Replace the login name with ${USER} and the password with ${PASS} on the appropriate samplers
* ユーザ名とパスワードを含むカンマ区切のテキストファイルを作成します。これをテスト計画と同じディレクトリに設置します。
* CSVデータ設定要素をテスト計画に追加します。変数に USER と PASS と命名します。
* 適切なサンプラのログイン名を ${USER}、パスワードを ${PASS} に置換します。
The CSV Data Set element will read a new line for each thread.
CSVデータ設定要素はそれぞれのスレッドにおいて新しい行を読み込みます。
16.6 Reducing resource requirements
16.6 リソースの要求を軽減する
Some suggestions on reducing resource usage.
リソース消費量を軽減するいくつかの提案があります。
* Use non-GUI mode: jmeter -n -t test.jmx -l test.jtl
* non-GUIモードを使用する: jmeter -n -t test.jmx -l test.jtl
* Use as few Listeners as possible; if using the -l flag as above they can all be deleted or disabled.
* 可能な限りリスナの数を減らす。-lフラグを上記で使用する場合には全てを削除するか無効にします。
* Rather than using lots of similar samplers, use the same sampler in a loop, and use variables (CSV Data Set) to vary the sample. Or perhaps use the Access Log Sampler. [The Include Controller does not help here, as it adds all the test elements in the file to the test plan.]
* 沢山のサンプラを使用するのではなく、同じサンプラによるループと変数(CSVデータ設定要素)によってサンプルを変更させるべきです。もしくはアクセスログサンプラを使用してください。[テスト計画のファイルに存在する全てのテスト要素を追加するような手助けを組み込みのコントローラは行いません。]
* Don't use functional mode
* functionalモードを使用しない。
* Use CSV output rather than XML
* XMLではなくCSV出力を使用する。
* Only save the data that you need
* 必要なデータだけを保存する。
* Use as few Assertions as possible
* できるだけ少ないアサーションを使用する。
16.7 BeanShell server
The BeanShell interpreter has a very useful feature - it can act as a server, which is accessible by telnet or http.
There is no security. Anyone who can connect to the port can issue any BeanShell commands. These can provide unrestricted access to the JMeter application and the host. Do not enable the server unless the ports are protected against access, e.g. by a firewall.
If you do wish to use the server, define the following in jmeter.properties:
beanshell.server.port=9000
beanshell.server.file=../extras/startup.bsh
In the above example, the server will be started, and will listen on ports 9000 and 9001. Port 9000 will be used for http access. Port 9001 will be used for telnet access. The startup.bsh file will be processed by the server, and can be used to define various functions and set up variables. The startup file defines methods for setting and printing JMeter and system properties. This is what you should see in the JMeter console:
Startup script running
Startup script completed
Httpd started on port: 9000
Sessiond started on port: 9001
As a practical example, assume you have a long-running JMeter test running in non-GUI mode, and you want to vary the throughput at various times during the test. The test-plan includes a Constant Throughput Timer which is defined in terms of a property, e.g. ${__P(throughput)}. The following BeanShell commands could be used to change the test:
printprop("throughput");
curr=Integer.decode(args[0]); // Start value
inc=Integer.decode(args[1]); // Increment
end=Integer.decode(args[2]); // Final value
secs=Integer.decode(args[3]); // Wait between changes
while(curr <= end){
setprop("throughput",curr.toString()); // Needs to be a string here
Thread.sleep(secs*1000);
curr += inc;
}
printprop("throughput");
The script can be stored in a file (throughput.bsh, say), and sent to the server using bshclient.jar. For example:
java -jar ../lib/bshclient.jar localhost 9000 throughput.bsh 70 5 100 60
16.8 BeanShell scripting
16.8.1 Overview
Each BeanShell test element has its own copy of the interpreter (for each thread). If the test element is repeatedly called, e.g. within a loop, then the interpreter is retained between invocations unless the "Reset bsh.Interpreter before each call" option is selected.
Some long-running tests may cause the interpreter to use lots of memory; if this is the case try using the reset option.
You can test BeanShell scripts outside JMeter by using the command-line interpreter:
$ java -cp bsh-xxx.jar[;other jars as needed] bsh.Interperter file.bsh [parameters]
or
$ java -cp bsh-xxx.jar bsh.Interperter
bsh% source("file.bsh");
bsh% exit(); // or use EOF key (e.g. ^Z or ^D)
16.8.2 Sharing Variables
Variables can be defined in startup (initialisation) scripts. These will be retained across invocations of the test element, unless the reset option is used.\
Scripts can also access JMeter variables using the get() and put() methods of the "vars" variable, for example: vars.get("HOST"); vars.put("MSG","Successful"); . The get() and put() methods only support variables with String values, but there are also getObject() and putObject() methods which can be used for arbitrary objects. JMeter variables are local to a thread, but can be used by all test elements (not just Beanshell).
If you need to share variables between threads, then JMeter properties can be used:
import org.apache.jmeter.util.JMeterUtils;
String value=JMeterUtils.getPropDefault("name","");
JMeterUtils.setProperty("name", "value");
The sample .bshrc files contain sample definitions of getprop() and setprop() methods.
Another possible method of sharing variables is to use the "bsh.shared" shared namespace. For example:
if (bsh.shared.myObj == void){
// not yet defined, so create it:
myObj=new AnyObject();
}
bsh.shared.myObj.process();
Rather than creating the object in the test element, it can be created in the startup file defined by the JMeter property "beanshell.init.file". This is only processed once.
英語勉強日記#10(翻訳がんばろう日記) More ログイン