パスワードを忘れた？ アカウント作成
Close

bananan_wさんのトモダチの日記、みんなの日記も見てね。 スラッシュドットのストーリーを選ぶための補助をお願いします。

907929 journal
日記

bananan_wの日記： 実験メモ

日記 by bananan_w

http://definitions.symantec.com/defs/
に定期的にファイルを取りに行くと、
「変」な事象が発生する場合がある。
定期的に監視して、動きを見てみたい。

試験用スクリプトは以下の通り。

#!/bin/sh
OLD="/dev/null"
while [ 1 ]; do
                wget --no-cache http://definitions.symantec.com/defs/ > /dev/null 2>&1
                diff $OLD index.html > /dev/null
                if [ $? -ne 0 ] ; then
                                NEW=index_`date +%Y%m%d%H%M`.html
                                mv index.html $NEW
                                OLD=$NEW
                else
                                rm index.html
                fi
                sleep 60
done

128240 journal

bananan_wの日記： 英語勉強日記#13(翻訳がんばろう日記)

日記 by bananan_w
久しぶりの翻訳頑張ろう日記。
最近、お仕事でJMeterでドハマリをしたので、BeanShelLの事もかけるようになりましたよ＞＜
と言うわけで、まったりと進めていきましょう。

18.2.13 Module Controller
18.2.13 モジュールコントローラ

The Module Controller provides a mechanism for substituting test plan fragments into the current test plan at run-time.
モジュールコントローラはテスト計画の断片を現在のテスト計画に実行時に挿入させる事を提供します。

A test plan fragment consists of a Controller and all the test elements (samplers etc) contained in it. The fragment can be located in any Thread Group, or on the WorkBench . If the fragment is located in a Thread Group, then its Controller can be disabled to prevent the fragment being run except by the Module Controller. Or you can store the fragments in a dummy Thread Group, and disable the entire Thread Group.
テスト計画の断片はコントローラに含まれるすべてのテスト要素(サンプラ等)によって構成されます。断片はワークベンチの任意のスレッドグループに存在可能です。断片がスレッドグループに存在する場合には、モジュールコントローラによって実行される事を防ぐため、コントローラを無効としておきます。または、スレッドグループ全体を無効としたダミーのスレッドグループに断片を設置できます。

There can be multiple fragments, each with a different series of samplers under them. The module controller can then be used to easily switch between these multiple test cases simply by choosing the appropriate controller in its drop down box. This provides convenience for running many alternate test plans quickly and easily.
複数の断片が存在可能であり、それぞれが異なる種類のサンプラを保持できます。モジュールコントローラのドロップダウンボックスの中の適切なコントローラを選ぶことによって、テストケースを容易に切り替える事ができます。これは沢山の逐次変更を行うテスト計画を簡単かつ手早く実行させることを提供します。

A fragment name is made up of the Controller name and all its parent names. For example:
断片の名前はコントローラ名と素のすべての親から生成されます。例：

Test Plan / Protocol: JDBC / Control / Interleave Controller (Module1)
テスト計画 / JDBCプロトコル / コントロール / インタリーブコントローラ(モジュール1)

Any fragments used by the Module Controller must have a unique name , as the name is used to find the target controller when a test plan is reloaded. For this reason it is best to ensure that the Controller name is changed from the default - as shown in the example above - otherwise a duplicate may be accidentally created when new elements are added to the test plan.
モジュールコントローラから使用される断片の名前は一意でなければなりません。テスト計画を再読み込みしたした場合に、対象コントローラを検索するために名前を使用します。コントローラの名前をデフォルトから変更する事で一意となることを保証できます。(以下の例の様に)さもなければ、テスト計画に新しい要素を追加した際に同じ名前のものが作られてしまうかもしれません。

Control Panel

The Module Controller should not be used with remote testing or non-gui testing in conjunction with Workbench components since the Workbench test elements are not part of test plan .jmx files. Any such test will fail.
モジュールコントローラはリモートテストやnon-GUIモードでは使用するべきではありません。これは、Workgroupコンポーネントは結合して以降、Workbenchテスト要素がテスト計画の.jmxファイルの一部ではなくなるためです。全てのそのようなテストは失敗するでしょう。

Parameters
Attribute    Description    Required
Name     Descriptive name for this controller that is shown in the tree.     No
Module to Run     The module controller provides a list of all controllers loaded into the gui. Select the one you want to substitute in at runtime.     Yes
実行させるモジュール    GUIから読み込んだ全てのコントローラのリストをモジュールコントローラが提供します。実行したいものを一つだけ選択します。    必須

18.2.14 Include Controller
18.2.14 インクルードコントローラ

The include controller is designed to use an external jmx file. To use it, add samples to a simple controller, then save the simple controller as a jmx file. The file can then be used in a test plan. The included test plan must not include a Thread Group. It should only contain the Simple Controller and any samplers, controllers etc below it.
インクルードコントローラは外部のjmxファイルを使用するために設計されています。これを使用するには、シンプルコントローラにサンプラを追加し、jmxファイルとして保存します。このファイルはテスト計画の中で使用する事ができます。インクルードされるファイルにはスレッドグループを含めてはなりません。シンプルコントローラと他のサンプラだけを含める事ができます。

If the test uses a Cookie Manager or User Defined Variables, these should be placed in the top-level test plan, not the included file, otherwise they are not guaranteed to work.
クッキーマネージャかユーザ定義変数をテスト中で使用する場合には、テスト計画のトップレベルに配置するべきであり、インクルードされる側のファイルには持たせないべきです。さもなければ、動作する保証はありません。

This element does not support variables/functions in the filename field.
However, if the property includecontroller.prefix is defined, the contents are used to prefix the pathname.
この要素は変数と関数をファイル名フィールドに仕様できません。
しかしながら、プロパティ includecontroller.prefix が定義されている場合には、prefixのパス名のコンテンツが使用されます。

Control Panel

Parameters
Attribute    Description    Required
Filename     The file to include.     Yes
ファイル名    インクルードするファイル名    必須
66304 journal

bananan_wの日記： 英語勉強日記#12(翻訳がんばろう日記)

日記 by bananan_w
いよいよ開幕。地獄の18章。ここがドキュメントのほぼ全てだっ。だけど、逆に言うと外堀は全部埋めた(BeanShellとかスルーしてるけど)形になっているので、サクサク翻訳が進められるはず。まぁ、この章は検証しながらになるから遅くなると思うけど。

18.1 Samplers
18.1 サンプラ

    Samplers perform the actual work of JMeter. Each sampler (except Test Action) generates one or more sample results. The sample results have various attributes (success/fail, elapsed time, data size etc) and can be viewed in the various listeners.
    サンプラがJMeterの本当の仕事を請け負います。それぞれのサンプラは(テスト動作を実施する)一つ以上のサンプル結果を生成します。サンプル結果はさまざまな属性(成功/失敗、経過時間、データサイズ等)を保持しており、各種リスナによって閲覧できます。

    18.1.1 FTP Request
    18.1.1 FTPリクエスト

    This controller lets you send an FTP "retrieve file" or "upload file" request to an FTP server. If you are going to send multiple requests to the same FTP server, consider using a FTP Request Defaults Configuration Element so you do not have to enter the same information for each FTP Request Generative Controller. When downloading a file, it can be stored on disk (Local File) or in the Response Data, or both.
    このコントローラはFTPサーバにFTPのダウンロードかアップロードリクエストを送信します。同一のFTPサーバに複数のリクエストを送信する場合、個々のFTPリクエストに同一の設定値を入力するのではなく、FTPリクエストデフォルト設定要素を使用してください。ダウンロードしたファイルをディスク(ローカルファイル)に保存するか、サンプル結果に含めるか、どちらもかを選択できます。

    Latency is set to the time it takes to login (versions of JMeter after 2.3.1).
    ログインにかかった時間がレイテンシに保存されます(JMeter 2.3.1以降)。

    Control Panel
    コントロールパネル

    Parameters
    Attribute    Description    Required
    Name     Descriptive name for this controller that is shown in the tree.     No
    名前    ツリー上に表示されるコントローラの名前    省略可

    Server Name or IP     Domain name or IP address of the FTP server. JMeter assumes the FTP server is listening on the default port.     Yes
    サーバ名又はIP    FTPサーバのドメイン名かIPアドレス。JMeterはFTPサーバがデフォルトポートで待ち受けているとみなします。    必須

    Remote File:     File to retrieve or name of destination file to upload.     Yes
    リモートファイル    ダウンロードかアップロードするファイル名。    必須(訳注:コロンが不要です)

    Local File:     File to upload, or destination for downloads (defaults to remote file name).     Yes, if uploading (*)
    ローカルファイル    アップロードかダウンロードして保存するファイル名(デフォルトはリモートファイル名です)。    アップロードするなら必須(*)(訳注:これもコロンが不要)

    Local File Contents:     Provides the contents for the upload, overrides the Local File property.     Yes, if uploading (*)
    ローカルファイルコンテンツ    アップロードするファイルの内容を記述します。ローカルファイルプロパティに優先します。    アップロードするなら必須(*)(訳注:これもコロン不要。また、画像が古くてこの項目が存在しない)

    get(RETR) / put(STOR)     Whether to retrieve or upload a file.     Yes
    get(RETR) / put(STOR)    ダウンロードかアップロードのどちらであるかを指定します。    必須

    Use Binary mode ?     Check this to use Binary mode (default Ascii)     Yes
    バイナリモードを使用    バイナリモードを使用するなら(デフォルトはASCII)チェックしてください。    必須

    Save File in Response ?     Whether to store contents of retrieved file in response data. If the mode is Ascii, then the contents will be visible in the Tree View Listener.     Yes, if downloading
    サンプル結果にファイルを保存する    サンプル結果にダウンロードしたファイルを含めるかを指定します。ASCIIモードである場合には、ツリービューリスナからファイルの中身を閲覧できます。    ダウンロードするなら必須

    Username     FTP account username.     Usually
    ユーザ名    FTPユーザアカウント名。    通常必要

    Password     FTP account password. N.B. This will be visible in the test plan.     Usually
    パスワード    FTPユーザアカウントのパスワード。テスト計画上からこの変数は参照可能です。    通常必要

    See Also:

        * Assertions
        * FTP Request Defaults
        * Building an FTP Test Plan

    18.1.2 HTTP Request
    18.1.2 HTTPリクエスト

    This sampler lets you send an HTTP/HTTPS request to a web server. It also lets you control whether or not JMeter parses HTML files for images and other embedded resources and sends HTTP requests to retrieve them. The following types of embedded resource are retrieved:
    このサンプラはHTTP/HTTPSリクエストをウェブサーバへ送信させます。また、HTMLファイルを解析して画像やその他のリソースを得るためにHTTPリクエストを送信するかを制御できます。以下の種類の組み込みリソースに対応しています:

        * images
        * applets
        * stylesheets
        * external scripts
        * frames
        * background images (body, table, TD, TR)
        * background sound

    The default parser is htmlparser. This can be changed by using the property "htmlparser.classname" - see jmeter.properties for details.
    デフォルトのパーサはhtmlparserです。プロパティ"htmlparser.classname"によって変更できます。詳細についてはjmeter.propertiesを参照してください。

    If you are going to send multiple requests to the same web server, consider using an HTTP Request Defaults Configuration Element so you do not have to enter the same information for each HTTP Request.
    同一のウェブサーバに複数のリクエストを送信する場合、個々のHTTPリクエストに同一の設定値を入力するのではなく、HTTPリクエストデフォルト設定要素を使用してください。

    Or, instead of manually adding HTTP Requests, you may want to use JMeter's HTTP Proxy Server to create them. This can save you time if you have a lot of HTTP requests or requests with many parameters.
    HTTPリクエストに手動で追加する代わりに、JMeterのHTTPプロキシサーバを使用して作成したいと思うかもしれません。大量のHTTPリクエストがある場合や大量のパラメータが存在する場合には、作業時間の短縮になるでしょう。

    There are three versions of the sampler:
    以下の三つのサンプラが存在します:

        * HTTP Request - uses the default Java HTTP implementation
        * HTTPリクエスト - JavaによるデフォルトのHTTPの実装を使用

        * HTTP Request HTTPClient - uses Apache Commons HttpClient
        * HTTPリクエストHTTPClient - ApacheコモンHttpClientを使用

        * AJP/1.3 Sampler - uses the Tomcat mod_jk protocol (allows testing of Tomcat in AJP mode without needing Apache httpd) The AJP Sampler does not support multiple file upload; only the first file will be used.
        * APJ/1.3サンプラ - Tomcat mod_jk プロトコルを使用(Apache httpd無しでTomcatをAPJモードでテストできます)。AJPサンプラは複数のファイルのアップロードに対応していません。始めのファイルだけが使用されるでしょう。

    The default (Java) implementation has some limitations:
    デフォルト(Java)の実装にはいくつかの制限があります:

        * There is no control over how connections are re-used. When a connection is released by JMeter, it may or may not be re-used by the same thread.
        * コネクション再利用の制御方法が存在しません。JMeterがコネクションを解放する時に、同じスレッドが再利用できるか否かは未確定です。

        * The API is best suited to single-threaded usage - various settings (e.g. proxy) are defined via system properties, and therefore apply to all connections.
        * APIはシングルスレッドの場合に最も適しています。変数設定(例、プロキシ)はシステムプロパティを経由して定義するため、全ての接続に対して変数は適用されます。

        * There is a bug in the handling of HTTPS via a Proxy (the CONNECT is not handled correctly). See Java bugs 6226610 and 6208335.
        * プロキシ経由のHTTPS(CONNECTが現在未実装です)の制御にバグが存在します。Javaバグ6226610と6208335を参照してください。

    Note: the FILE protocol is intended for testing puposes only. It is handled by the same code regardless of which HTTP Sampler is used.
    注意: FILEプロトコルはテストする目的に限定して使用してください。HTTPサンプラと同じコードを無頓着に流用して実装されています。

    If the request requires server or proxy login authorization (i.e. where a browser would create a pop-up dialog box), you will also have to add an HTTP Authorization Manager Configuration Element. For normal logins (i.e. where the user enters login information in a form), you will need to work out what the form submit button does, and create an HTTP request with the appropriate method (usually POST) and the appropriate parameters from the form definition. If the page uses HTTP, you can use the JMeter Proxy to capture the login sequence.
    リクエストがサーバかプロキシのログイン認証を要求する場合には(例えば、ブラウザがポップアップダイアログボックスを作成するような)、HTTP認証マネージャ設定要素を追加する必要があります。通常のログイン(例えば、ユーザがフォームにログイン情報を入力する形のもの)では、フォームのsubmitボタンの処理を解析する必要があり、適切なメソッド(通常POST)で、フォームに定義された適切なパラメータを持つHTTPリクエストを生成します。ページがHTTPを使用する場合には、JMeterプロキシでログインシーケンスをキャプチャできます。

    In versions of JMeter up to 2.2, only a single SSL context was used for all threads and samplers. This did not generate the proper load for multiple users. A separate SSL context is now used for each thread. To revert to the original behaviour, set the JMeter property:
    JMeter version 2.2迄では、一つのSSLコンテキストを全てのスレッドとサンプラで共有していました。これは複数ユーザに適した負荷を生成できません。SSLコンテキストは現在ではそれぞれのスレッドで分割して使用されています。以前の状態に戻すにはJMeterプロパティを設定します。

https.sessioncontext.shared=true

    JMeter defaults to the SSL protocol level TLS. If the server needs a different level, e.g. SSLv3, change the JMeter property, for example:
    JMeterのデフォルトSSLプロトコルレベルはTLSです。サーバが異なるレベル(SSLv3等)を必要とする場合には、JMeterプロパティを変更してください。例:

https.default.protocol=SSLv3

    If the request uses cookies, then you will also need an HTTP Cookie Manager . You can add either of these elements to the Thread Group or the HTTP Request. If you have more than one HTTP Request that needs authorizations or cookies, then add the elements to the Thread Group. That way, all HTTP Request controllers will share the same Authorization Manager and Cookie Manager elements.
    リクエストがクッキーを使用する場合、HTTPクッキーマネージャが必要になるでしょう。スレッドグループかHTTPリクエストのどちらにも要素を追加できます。一つ以上のHTTPリクエストが認証かクッキーを必要とする場合には、スレッドグループに追加します。この方法では全てのHTTPリクエストが同じ認証マネージャ要素やクッキーマネージャ要素を共有して管理されます。

    If the request uses a technique called "URL Rewriting" to maintain sessions, then see section 6.1 Handling User Sessions With URL Rewriting for additional configuration steps.
    セッションを保持するために"URLリライティング"と呼ばれるテクニックをリクエストが使用している場合には、6.1 Handling User Sessions With URL Rewriting (訳注:Aタグ注意)を参照して追加設定を行なってください。

    Control Panel
    コントロールパネル

    Parameters
    Attribute    Description    Required
    Name     Descriptive name for this controller that is shown in the tree.     No
    名前    ツリー上に表示されるコントローラの名前    省略可

    Server     Domain name or IP address of the web server. e.g. www.example.com. [Do not include the http:// prefix.]     No
    サーバ    ウェブサーバのドメイン名かIPアドレス。例、www.example.com。[プレフィックス http:// を含めないで下さい。] 省略可

    Port     Port the web server is listening to. Default: 80     No
    ポート    ウェブサーバが待ち受けするポート番号。デフォルト：80    省略可

    Protocol     HTTP, HTTPS or FILE. Default: HTTP     No
    プロトコル    HTTP、HTTPS、FILEのいずれか。デフォルト：HTTP    省略可

    Method     GET, POST, HEAD, TRACE, OPTIONS, PUT, DELETE     Yes
    メソッド    GET、POST、HEAD、TRACE、OPTIONS、PUT、DELETEのいずれか。    必須

    Content Encoding     Content encoding to be used (for POST and FILE)     No
    Content Encoding     使用するContent Encoding(POSTかFILEにて)。    省略可

    Redirect Automatically     Sets the underlying http protocol handler to automatically follow redirects, so they are not seen by JMeter, and thus will not appear as samples. Should only be used for GET and HEAD requests. The HttpClient sampler will reject attempts to use it for POST or PUT. Warning: see below for information on cookie and header handling.     Yes
    自動リダイレクト    基礎的なHTTPプロトコルハンドラに自動リダイレクトを実施させる場合にセットし、JMeterからは見られません。そしてそれらはサンプルに現れません。GETかHEADのリクエストの場合だけに使用を止めるべきです。HTTPClientサンプラはPOSTとPUTの場合には要求を却下します。注意：以下のクッキーとヘッダの取り扱いに関する情報を参照してください。    必須(訳注:**もんのすごく勢いに任せて書いてるんで必ず見直してから仕上げること**)

    Follow Redirects     This only has any effect if "Redirect Automatically" is not enabled. If set, the JMeter sampler will check if the response is a redirect and follow it if so. The redirect response will appear as an additional sample. Note that the HttpClient sampler may log the following message:
    This can be ignored.     Yes
    リダイレクトをたどる    "自動リダイレクト"が有効ではない場合にこれは効力を発揮します。セットした場合には、JMeterのサンプラはレスポンスがリダイレクトでありそれをたどれるかを確認します。リダイレクトされたレスポンスは追加したサンプルのように見えます。HttpClientサンプラはログに以下のメッセージを出力することに注意してください。

    "Redirect requested but followRedirects is disabled"

    Use KeepAlive     JMeter sets the Connection: keep-alive header. This does not work properly with the default HTTP implementation, as connection re-use is not under user-control. It does work with the Jakarta httpClient implementation.     Yes
    KeepAliveを使用する    JMeterに Connection: keep-alive ヘッダを使用するように設定します。これはデフォルトのHTTPの実装が適切にされていないためうまく動作しません。コネクションの再使用をユーザが制御できないためです。
Jakarta httpClient による実装では動作します。    必須

    Use multipart/form-data for HTTP POST     Use a multipart/form-data or application/x-www-form-urlencoded post request     Yes
    multipart/form-dataをHTTP POSTに使用する    multipart/form-data又はapplication/x-www-form-urlencoded をPOSTリクエストで使用します。    必須

    Path     The path to resource (for example, /servlets/myServlet). If the resource requires query string parameters, add them below in the "Send Parameters With the Request" section. As a special case, if the path starts with "http://" or "https://" then this is used as the full URL. In this case, the server, port and protocol are ignored; parameters are also ignored for GET and DELETE methods.     Yes
    パス    リソースのパス(例えば、/servlets/myServlet)。リソースがクエリーストリングパラメータを要求する場合には、以下の"リクエスト時に送信するパラメータ"を参照してください。パスが"https://"で開始する完全なURLである場合には、特別なケースです。この場合、サーバ、ポート、プロトコルは無視されます。パラメータはGETとDELETEメソッド以外のパラメータを無視します。    必須

    Send Parameters With the Request     The query string will be generated from the list of parameters you provide. Each parameter has a name and value , the options to encode the parameter, and an option to include or exclude an equals sign (some applications don't expect an equals when the value is the empty string). The query string will be generated in the correct fashion, depending on the choice of "Method" you made (ie if you chose GET or DELETE, the query string will be appended to the URL, if POST or PUT, then it will be sent separately). Also, if you are sending a file using a multipart form, the query string will be created using the multipart form specifications. See below for some further information on parameter handling.
    リクエスト時に送信するパラメータ    クエリーストリングは用いるパラメータのリストによって生成されます。それぞれのパラメータには名前と値が存在し、パラメータのエンコードを行うオプションと、等記号を追加するかしないか(いくつかのアプリケーションは値が空文字列の場合に等記号が存在することを期待していません。)のオプションが存在します。クエリーストリングは正しく生成され、選択した"メソッド"とは独立して生成されます(例えば、GETかDELETEを選択した場合には、クエリーストリングはURLに追加されますが、POSTかPUTである場合には分割して送信されます)。マルチパートフォームを使用してファイルを送信する場合には、クエリーストリングはマルチパートフォームの仕様に従って生成されます。以下で説明するパラメータ制御を参照してください。

    Additionally, you can specify whether each parameter should be URL encoded. If you are not sure what this means, it is probably best to select it. If your values contain characters such as & or spaces, or question marks, then encoding is usually required.
        No
    加えて、それぞれのパラメータはURLエンコードするべきか否かに関わらず指定できます。これが何を意味するか自信がない場合には、それを選択することが大概最前策です。「&」か「?」か空白文字が値に含まれる場合には、エンコーディングが通常必要です。    省略可

    File Path:     Name of the file to send. If left blank, JMeter does not send a file, if filled in, JMeter automatically sends the request as a multipart form request.
    ファイルパス    送信するファイルの名前。左側が空である場合には、JMeterはファイルを送信しません。左側のフィールドに入力がある場合には、JMeterはリクエストを自動的にマルチパートフォームのリクエストとして送信します。

    If it is a POST or PUT request and there is a single file whose 'name' attribute (below) is omitted, then the file is sent as the entire body of the request, i.e. no wrappers are added. This allows arbitrary bodies to be sent. This functionality is present for POST requests after version 2.2, and also for PUT requests after version 2.3. See below for some further information on parameter handling.
        No
    POSTかPUTリクエストであり且つファイルが一つだけである場合には'名前'属性(後で記します)は無視され、ファイルはラッパを追加することなく完全なリクエストボディとして送信されます。任意のボディを送信することができます。この機能はPOSTリクエストはバージョン2.2から、PUTリクエストはバージョン2.3から提供されました。以下で説明するパラメータ制御を参照してください。    省略可

    Parameter name:     Value of the "name" web request parameter.     No
    パラメータ名    ウェブリクエストパラメータの"名前"の値。    省略可(訳注:この前後で"name"といわれているのってこれのこと？)

    MIME Type     MIME type (for example, text/plain). If it is a POST or PUT request and either the 'name' atribute (below) are omitted or the request body is constructed from parameter values only, then the value of this field is used as the value of the content-type request header.     No
    MIME Type    MIME type(例えば text/plain)。POSTかPUTリクエストであるか、'名前'属性(後で記述します(訳注:このすぐ上のじゃないの？))が省略されているか、リクエストボディがパラメータの値だけで構成されている場合に、content-typeヘッダの値としてこのフィールドの値が使用されます。    省略可

    Retrieve All Embedded Resources from HTML Files     Tell JMeter to parse the HTML file and send HTTP/HTTPS requests for all images, Java applets, JavaScript files, CSSs, etc. referenced in the file. See below for more details.     No
    HTMLファイルに組み込まれた全てのリソースを取得    HTMLファイルを解析してHTTP/HTTPSリクエストを全ての画像、Javaアプレット、JavaScriptファイル、CSS等に送信するようにJMeterに指示します。以下の詳細を参照してください。    省略可

    Use as monitor     For use with the Monitor Results listener.     Yes
    モニタとして使用する    モニタリザルトリスナと共に使用します。    必須

    Save response as MD5 hash?     If this is selected, then the response is not stored in the sample result. Instead, the 32 character MD5 hash of the data is calculated and stored instead. This is intended for testing large amounts of data.     Yes
    応答をMD5ハッシュで保存する    これを選択すると、サンプル結果にレスポンスを保存しません。その代わりに、32文字のMD5ハッシュ値を計算して保存します。これは巨大なデータをテストする場合を意識しています。

    Embedded URLs must match:     If present, this must be a regular expression that is used to match against any embedded URLs found. So if you only want to download embedded resources from http://example.com/, use the expression: http://example\.com/.*     No
    マッチしなければならない組み込みURL    指定する場合には、正規表現を入力します。組み込みURLが見つかった場合には、その正規表現とマッチするかを確認します。組み込みリソースを http://example.com/ だけからダウンロードさせたい場合には次の正規表現を使用します。http://example\.com/.* 。    省略可

    N.B. when using Automatic Redirection, cookies are only sent for the initial URL. This can cause unexpected behaviour for web-sites that redirect to a local server. E.g. if www.example.com redirects to www.example.co.uk. In this case the server will probably return cookies for both URLs, but JMeter will only see the cookies for the last host, i.e. www.example.co.uk. If the next request in the test plan uses www.example.com, rather than www.example.co.uk, it will not get the correct cookies. Likewise, Headers are sent for the initial request, and won't be sent for the redirect. This is generally only a problem for manually created test plans, as a test plan created using a recorder would continue from the redirected URL.
    注意：自動リダイレクトを使用する場合には、クッキーは最初のURLだけに送信される事に注意してください。これはローカルサーバへリダイレクトするウェブサーバで予期しない動作を引き起こします。例えば、www.example.com が www.example.com.uk にリダイレクトする場合、サーバは高確立で両方のURLへのクッキーを返却しますが、JMeterは最後のホストのクッキーだけを参照します。例：www.example.co.uk。テスト計画が次のリクエストを www.example.co.uk ではなく www.example.com へ送信する場合、適切なクッキーを取得できません。同様に、ヘッダは最初のリクエストのために送信され、リダイレクトのためには送信されません。これは通常は手動で作られたテスト計画だけに発生する問題で、レコーダを使用してテスト計画を作成した場合にはリダイレクトしたURLへ処理が継続するでしょう。

    Parameter Handling:
    パラメータ制御:
    For the POST and PUT method, if there is no file to send, and the name(s) of the parameter(s) are omitted, then the body is created by concatenating all the value(s) of the parameters. This allows arbitrary bodies to be sent. The values are encoded if the encoding flag is set (versions of JMeter after 2.3). See also the MIME Type above how you can control the content-type request header that is sent.
    POSTとPUTメソッドでは、ファイルを送信しない且つパラメータの名前が省略された場合には、全てのパラメータを連結したものがボディとして生成されます。これは任意のボディを送信できます。エンコードフラグが設定されている場合には値はエンコードされます(JMeterバージョン2.3以降)。上記のMIME Typeを参照して content-type リクエストヘッダを制御して設定する方法を確認してください。

    For other methods, if the name of the parameter is missing, then the parameter is ignored. This allows the use of optional parameters defined by variables. (versions of JMeter after 2.3)
    他のメソッドには、パラメータが存在しない場合には、そのパラメータは無視されます。変数にオプションのパラメータを設定する事に使用できます(JMeterバージョン2.3以降)。

    Method Handling:
    メソッド制御:
    The POST and PUT request methods work similarly, except that the PUT method does not support multipart requests. The GET and DELETE request methods work similarly.
    POSTとPUTリクエストメソッドは類似した動作をしますが、例外としてPOSTメソッドはマルチパートリクエストをサポートしていません。GETとDELETEリクエストは類似した動作をします。

    Upto and including JMeter 2.1.1, only responses with the content-type "text/html" were scanned for embedded resources. Other content-types were assumed to be something other than HTML. JMeter 2.1.2 introduces the a new property HTTPResponse.parsers , which is a list of parser ids, e.g. htmlParser and wmlParser . For each id found, JMeter checks two further properties:
    JMeter 2.1.1までは、レスポンスのcontent-typeが"text/html"であるものだけが組み込みリソースのサーチ対象でした。他の content-type はHTMLではないものだと見なされていました。JMeter 2.1.2 は新しいプロパティ HTTPResponse.parsers を導入しました。それはパーサのIDのリストです。例：htmlParser と wmlParser。それぞれのIDを見つけると、JMeterは二つのプロパティを確認します。

        * id.types - a list of content types
        * id.className - the parser to be used to extract the embedded resources
        * id.types - content typeのリスト
        * id.className - 組み込みリソースを抽出するために使用するパーサ

    See jmeter.properties file for the details of the settings. If the HTTPResponse.parser property is not set, JMeter reverts to the previous behaviour, i.e. only text/html responses will be scanned
    詳細な設定方法に関しては jmeter.properties ファイルを参照してください。HTTPResponse.parserプロパティが設定されていない場合には、JMEterは以前と同様の振る舞いを行います。text/htmlのレスポンスだけがサーチされます。

    See Also:

        * Assertion
        * Building a Web Test Plan
        * Building an Advanced Web Test Plan
        * HTTP Authorization Manager
        * HTTP Cookie Manager
        * HTTP Header Manager
        * HTML Link Parser
        * HTTP Proxy Server
        * HTTP Request Defaults
        * HTTP Requests and Session ID's: URL Rewriting
(訳注:後で全部リンクはること。)

18.2 Logic Controllers
18.2 ロジックコントローラ

    Logic Controllers determine the order in which Samplers are processed.
    ロジックコントローラは散布羅の実行する順番を決定します。

    18.2.1 Simple Controller
    18.2.1 シンプルコントローラ

    The Simple Logic Controller lets you organize your Samplers and other Logic Controllers. Unlike other Logic Controllers, this controller provides no functionality beyond that of a storage device.
    シンプルロジックコントローラはサンプラと他のロジックコントローラを束ねさせます。他のロジックコントローラとは異なり、このコントローラには関数によるストレージデバイスは提供されません。

    Control Panel
    コントロールパネル

    Parameters
    Attribute    Description    Required
    Name     Descriptive name for this controller that is shown in the tree.     No
    名前    ツリー上に表示されるコントローラの名前    省略可

    Using the Simple Controller
    シンプルコントローラを使用する

    Download this example (see Figure 6). In this example, we created a Test Plan that sends two Ant HTTP requests and two Log4J HTTP requests. We grouped the Ant and Log4J requests by placing them inside Simple Logic Controllers. Remember, the Simple Logic Controller has no effect on how JMeter processes the controller(s) you add to it. So, in this example, JMeter sends the requests in the following order: Ant Home Page, Ant News Page, Log4J Home Page, Log4J History Page. Note, the File Reporter is configured to store the results in a file named "simple-test.dat" in the current directory.
    この例(図6(訳注:なんでいきなり図6なんですか？18-nじゃないの？)を参照してください)をダウンロードしてください。この例では、テスト計画に二つのAnt HTTPリクエストと二つのLog4J HTTPリクエストを生成します。シンプルロジックコントローラの中にAntとLog4Jリクエストを格納してグループ化しています。(訳注:シンプルコントローラ？シンプルロジックコントローラ？どっち？統一しましょう。)シンプルロジックコントローラは追加するコントローラに対してJMeterに何の影響も与えない事を忘れないでください。この例では、JMeterは次の順番でリクエストを送信します。Ant Home Page、Ant News Page、Log4J Home Page、Log4J History Pageの順です。File Reporterは"simple-test.dat"という名前でカレントディレクトリに結果を保存します。

    Figure 6 Simple Controller Example
    図6 シンプルコントローラ例(訳注:18-nにする事)

    18.2.2 Loop Controller
    18.2.2 ループコントローラ

    If you add Generative or Logic Controllers to a Loop Controller, JMeter will loop through them a certain number of times, in addition to the loop value you specified for the Thread Group. For example, if you add one HTTP Request to a Loop Controller with a loop count of two, and configure the Thread Group loop count to three, JMeter will send a total of 2 * 3 = 6 HTTP Requests.
    ループコントローラにロジックコントローラか他の生成するものを追加する場合、JMeterは指定の回数繰返し処理を行い、スレッドグループに指定したループ数の加算を行います。例えば、ループコントローラにループ数を2と指定してHTTPリクエストを一つ追加し、スレッドグループのループ数に3を指定した場合には、JMeterは合計で 2 * ３ = 6 HTTPリクエストを送信します。

    Control Panel
    コントロールパネル

    Parameters
    Attribute    Description    Required
    Name     Descriptive name for this controller that is shown in the tree.     No
    名前    ツリー上に表示されるコントローラの名前    省略可

    Loop Count     The number of times the subelements of this controller will be iterated each time through a test run.
    ループ数    このコントローラのサブ要素がテストの実行の際に繰り返し処理される回数。

    Special Case: The Loop Controller embedded in the Thread Group element behaves slightly differently. Unless set to forever, it stops the test after the given number of iterations have been done.
        Yes, unless "Forever" is checked
    例外事項: スレッドグループ要素に組み込まれたループコントローラは若干異なる挙動を示します。無限ループを指定しない限り、指定したループ回数を実行した後に停止します。

    Looping Example
    ループの例

    Download this example (see Figure 4). In this example, we created a Test Plan that sends a particular HTTP Request only once and sends another HTTP Request five times.
    この例(図4(訳注:図6の次が4ですか？)を参照してください)をダウンロードしてください。この例では、特別なHTTPリクエストを一度だけ送信し、そうでないHTTPリクエストを5回送信しています。

    Figure 4 - Loop Controller Example
    図4(訳注:図表番号は後で直すこと) - ループコントローラの例

    We configured the Thread Group for a single thread and a loop count value of one. Instead of letting the Thread Group control the looping, we used a Loop Controller. You can see that we added one HTTP Request to the Thread Group and another HTTP Request to a Loop Controller. We configured the Loop Controller with a loop count value of five.
    シングルスレッドでループ回数が1のスレッドグループを設定しました。スレッドグループコントローラのループとループコントローラは独立しています。一度送信するHTTPリクエストがスレッドグループ直下に存在し、他のHTTPリクエストはループコントローラ直下に存在しています。ループコントローラのループ回数は5に設定しています。

    JMeter will send the requests in the following order: Home Page, News Page, News Page, News Page, News Page, and News Page. Note, the File Reporter is configured to store the results in a file named "loop-test.dat" in the current directory.
    JMeterは次の順番でリクエストを送信します。Home Page、News Page、News Page、News Page、 News Page、News Pageの順です。File Reporterは"loop-test.dat"という名前でカレントディレクトリに結果を保存します。

18.2.4 Interleave Controller
18.2.4 インタリーブコントローラ

If you add Generative or Logic Controllers to an Interleave Controller, JMeter will alternate among each of the other controllers for each loop iteration.
Generativeかロジックコントローラにインタリーブコントローラを追加すると、JMeterは他のコントローラを交互に選択し、そのコントローラのループを繰り返しを行うでしょう。

Control Panel
コントロールパネル

Parameters
Attribute    Description    Required
name     Descriptive name for this controller that is shown in the tree.     No
名前    ツリー上で表示されるコントローラの名前    省略可

ignore sub-controller blocks     If checked, the interleave controller will treat sub-controllers like single request elements and only allow one request per controller at a time.     No
サブコントローラブロックを無視する    チェックした場合には、インタリーブコントローラはサブコントローラを単一のリクエスト要素として扱い、コントローラに一度に一つだけのリクエストを送信することを許可します。    省略可

Simple Interleave Example
単純なインタリーブの例

Download this example (see Figure 1). In this example, we configured the Thread Group to have two threads and a loop count of five, for a total of ten requests per thread. See the table below for the sequence JMeter sends the HTTP Requests.
この例をダウンロードしてください(図1を参照してください)。(訳注:図18-nであるべき)この例ではスレッドグループのスレッド数は2、ループ数は5、合計で10リクエストがスレッド毎に送信されます。以下の表のJMeterが送信するHTTPリクエストのシーケンスを参照してください。

Figure 1 - Interleave Controller Example 1
図1 - インタリーブコントローラの例1

Loop Iteration     Each JMeter Thread Sends These HTTP Requests
ループの繰り返し     それぞれのJMeterスレッドが送信するHTTPリクエスト
1     News Page
1     Log Page
2     FAQ Page
2     Log Page
3     Gump Page
3     Log Page
4     Because there are no more requests in the controller,
JMeter starts over and sends the first HTTP Request, which is the News Page.
4     このコントローラにはリクエストが残っていないので、
JMeterは最初(News Page)のHTTPリクエストを送信します。
4     Log Page
5     FAQ Page
5     Log Page

Useful Interleave Example
便利なインタリーブの例

Download another example (see Figure 2). In this example, we configured the Thread Group to have a single thread and a loop count of eight. Notice that the Test Plan has an outer Interleave Controller with two Interleave Controllers inside of it.
他の例をダウンロードしてください(図2を参照してください)(訳注：だから18-2-4-1とかにしたら？)。この例ではスレッドグループはシングルスレッドでループ回数は8です。二つのインタリーブコントローラを中に持つインタリーブコントローラがテスト計画に存在します。

Figure 2 - Interleave Controller Example 2
図2 - インタリーブコントローラの例2

The outer Interleave Controller alternates between the two inner ones. Then, each inner Interleave Controller alternates between each of the HTTP Requests. Each JMeter thread will send the requests in the following order: Home Page, Interleaved, Bug Page, Interleaved, CVS Page, Interleaved, and FAQ Page, Interleaved. Note, the File Reporter is configured to store the results in a file named "interleave-test2.dat" in the current directory.
外側のインタリーブコントローラは内部に存在する二つのインタリーブコントローラを交互に選択します。それぞれの内部のインタリーブコントローラはそれぞれのHTTPリクエストを相互に選択します。それぞれのJMeterのスレッドは以下の順番でリクエストを送信します。Home Page、Interleaved、Bug Page、Interleaved、CVS Page、Interleaved、FAQ Page、Interleavedです。ファイルレポータ(訳注:むしろ Simple Data Writerではないか？)は結果を"interleave-test2.dat"と言うファイル名で保存するように設定されていることに注意してください。(訳注:実はされてないんだけど)

Figure 3 - Interleave Controller Example 3
図3 - インタリーブコントローラ例3(訳注:だから図18.2.4-3にしようよ)

If the two interleave controllers under the main interleave controller were instead simple controllers, then the order would be: Home Page, CVS Page, Interleaved, Bug Page, FAQ Page, Interleaved. However, if "ignore sub-controller blocks" was checked on the main interleave controller, then the order would be: Home Page, Interleaved, Bug Page, Interleaved, CVS Page, Interleaved, and FAQ Page, Interleaved.
インタリーブコントローラの代わりにシンプルコントローラが二つのインタリーブコントローラの親であった場合には、順序は以下の通りです。Home Page、CVS Page、Interleaved、Bug Page、FAQ Page、Interleavedです。また、親のインタリーブコントローラの"サブコントローラブロックを無視する"がチェックされている場合には、順番は以下の通りです。Home Page、Interleaved、Bug Page、Interleaved、CVS Page、Interleaved、FAQ Page、Interleavedです。

18.2.5 Random Controller
18.2.5 ランダムコントローラ

The Random Logic Controller acts similarly to the Interleave Controller, except that instead of going in order through its sub-controllers and samplers, it picks one at random at each pass.
ランダムロジックコントローラはインタリーブコントローラと同じように振る舞いますが、順番にサブコントローラやサンプラを処理する代わりに、一度の処理で処理対象を一つだけ選択します。

Interactions between multiple controllers can yield complex behavior. This is particularly true of the Random Controller. Experiment before you assume what results any given interaction will give
複数のコントローラとの間の相互作用は複雑な挙動をもたらします。これはまさしくランダムコントローラに関しても当てはまります。与えられるいかなる相互作用による結果を推定する前の実験で有用です。

Control Panel

Parameters
Attribute    Description    Required
Name     Descriptive name for this controller that is shown in the tree.     No
名前    ツリー上に表示されるコントローラの名前    省略可

18.2.6 Random Order Controller
18.2.6 ランダム順序コントローラ

The Random Order Controller is much like a Simple Controller in that it will execute each child element at most once, but the order of execution of the nodes will be random.
ランダム順序コントローラはシンプルコントローラによく似ています。それぞれの子要素は一度だけ実行され、ノードの実行順序はランダムです。

Control Panel
(訳注:図18.2.6-1ってやるのやめちゃったの？)

Parameters
Attribute    Description    Required
Name     Descriptive name for this controller that is shown in the tree.     No
名前    ツリー上に表示されるコントローラの名前    省略可

18.2.7 Throughput Controller
18.2.7 スループットコントローラ

This controller is badly named, as it does not control throughput. Please refer to the Constant Throughput Timer for an element that can be used to adjust the throughput.
このコントローラは悪い名前が付けられています。スループットの制御は行ないません。スループットに関しては定数スループットタイマ要素を参照してください。

The Throughput Controller allows the user to control how often it is executed. There are two modes - percent execution and total executions. Percent executions causes the controller to execute a certain percentage of the iterations through the test plan. Total executions causes the controller to stop executing after a certain number of executions have occurred. Like the Once Only Controller, this setting is reset when a parent Loop Controller restarts.
スループットコントローラはどのくらいの頻度で実行するかを制御します。パーセント実行と合計実行回数の二つのモードがあります。パーセント実行はテスト計画における繰り返される処理のうち指定の割合でコントローラが実行されるかを決定します。合計実行回数は指定回数コントローラの処理を実行した以降では処理を行いません。一度だけ実行のコントローラに類似しており、この設定はパーセント実行ループコントローラが再起動した時にリセットされます。

Control Panel

The Throughput Controller can yield very complex behavior when combined with other controllers - in particular with interleave or random controllers as parents (also very useful).
スループットコントローラは他のコントローラと組み合わせることで非常に複雑な挙動を生成できます。具体的にはインタリーブやランダムコントローラを親とした場合です(これらは大変便利です)。

Parameters
Attribute    Description    Required
Name     Descriptive name for this controller that is shown in the tree.     No
名前    ツリー上に表示されるコントローラの名前    省略可

Execution Style     Whether the controller will run in percent executions or total executions mode.     Yes
実行スタイル    コントローラがパーセント実行か実行回数モードのどちらであるか    必須

Throughput     A number. for percent execution mode, a number from 0-100 that indicates the percentage of times the controller will execute. "50" means the controller will execute during half the iterations throught the test plan. for total execution mode, the number indicates the total number of times the controller will execute.     Yes
スループット    数字。パーセント実行モードでは数字は0-100の範囲で、コントローラを実行する確立(パーセント)を指定します。"50"の場合にはコントローラはテスト計画の繰り返しにおいて半分だけ実行されます。合計実行回数モードの場合には、数字はコントローラの実行される回数を意味します。    必須

Per User     If checked, per user will cause the controller to calculate whether it should execute on a per user (per thread) basis. if unchecked, then the calculation will be global for all users. for example, if using total execution mode, and uncheck "per user", then the number given for throughput will be the total number of executions made. if "per user" is checked, then the total number of executions would be the number of users times the number given for throughput.     No
ユーザ毎にカウントする    チェックされている場合には、コントローラの実行回数はユーザ毎(スレッド毎)を元に計算されます。チェックされていない場合には、計算は全てのユーザに対してグローバルに行われます。例えば、合計実行回数モードにおいて、"ユーザ毎にカウントする"をチェックしていない場合には、スループットに指定された数値が合計実行回数となります。"ユーザ毎"がチェックされている場合には、合計実行回数はスループットに指定した値をユーザ数で掛けた値となります。

18.2.8 Runtime Controller
18.2.8 実行時間コントローラ

The Runtime Controller controls how long its children are allowed to run.
実行時間コントローラはその子供が動作を許可される時間を制御します。

Control Panel

Parameters
Attribute    Description    Required
Name     Descriptive name for this controller that is shown in the tree, and used to name the transaction.     Yes
名前    ツリー上に表示されるコントローラの名前と、トランザクションで使用する名前。    必須

Runtime (seconds)     Desired runtime in seconds     Yes
実行時間(秒)    実行時間を秒単位で指定。    必須

18.2.9 If Controller
18.2.9 Ifコントローラ

The If Controller allows the user to control whether the test elements below it (its children) are run or not.
Ifコントローラは配下(自身の子)のテスト要素を実行するか否かを制御します。

Prior to JMeter 2.3RC3, the condition was evaluated for every runnable element contained in the controller. This sometimes caused unexpected behaviour, so 2.3RC3 was changed to evaluate the condition only once on initial entry. However, the original behaviour is also useful, so versions of JMeter after 2.3RC4 have an additional option to select the original behaviour.
JMeter 2.3RC3より前のJMeterでは、コントローラに含まれる全ての実行可能な要素は毎回条件を判断して実行するかを判定していました。これは度々予期しない挙動を引き起こしました。そのため2.3RC3は最初の一度目でだけで判定を行うように変更されました。しかしながら、古い実装も便利なものですので、JMeter 2.3RC4以降では追加オプションによって古い挙動を選択できます。

Control Panel

Parameters
Attribute    Description    Required
Name     Descriptive name for this controller that is shown in the tree.     No
名前    ツリー上に表示されるコントローラの名前

Condition     Javascript code that returns "true" or "false"     Yes
条件    "true"か"false"を返却するJavascriptコード

Evaluate for all children     Should condition be evaluated for all children? If not checked, then the condition is only evaluated on entry.     Yes
全ての子を判定する    条件を全ての子要素に対して判定しますか？チェックしない場合には、条件を一つの要素に対してだけ判定します。    必須

Examples:
例:

    * ${COUNT} < 10
    * "${VAR}" == "abcd"
    * ${JMeterThread.last_sample_ok} (check if last sample succeeded)

If there is an error interpreting the code, the condition is assumed to be false, and a message is logged in jmeter.log.
コードにエラーが存在する場合には、条件はfalseと判定され、jmeter.logにログが出力されます。

18.2.10 While Controller
18.2.10 Whileコントローラ

The While Controller runs its children until the condition is "false".
Whileコントローラは条件が"false"となるまでの間、子要素を実行し続けます。

Possible condition values:
設定可能な条件値:

    * blank - exit loop when last sample in loop fails
    * LAST - exit loop when last sample in loop fails. If the last sample just before the loop failed, don't enter loop.
    * Otherwise - exit (or don't enter) the loop when the condition is equal to the string "false"
    * blank - ループ中のサンプルが失敗した場合にループを終了します。
    * LAST - ループ中のサンプルが失敗した場合にループを終了します。ループの最後のサンプルが失敗した場合にはループに再入させません。
    * その他 - 条件が文字列"false"と一致する場合にループを終了します(又は再入しない)。

In contrast to the IfController, the condition is not evaluated as a JavaScript expression. The condition can be any variable or function that eventually evaluates to the string "false". This allows the use of JavaScript, BeanShell, properties or variables as needed.
Ifコントローラと比較して、条件はJavaスクリプトと評価されない違いがあります。条件は最終的に文字列"false"を返却するどのような変数や関数を使用できます。これはつまり、javaスクリプト、BeanShellスクリプト、プロパティ、変数を必要に応じて使用する事を実現します。

For example:
例：

    * ${VAR} - where VAR is set to false by some other test element
    * ${__javaScript(${C}==10,dummy)}
    * ${__javaScript("${VAR2}"=="abcd",dummy)}
    * ${_P(property)} - where property is set to "false" somewhere else

Control Panel

Parameters
Attribute    Description    Required
Name     Descriptive name for this controller that is shown in the tree, and used to name the transaction.     Yes
名前    ツリー上でコントローラの表示される名前と、トランザクションで使用される名前。    必須

Condition     blank, LAST, or variable/function     Yes
条件    blank、LAST、変数名/関数名のいずれか    必須

18.2.11 Switch Controller
18.2.11 Switchコントローラ

The Switch Controller acts like the Interleave Controller in that it runs one of the subordinate elements on each iteration, but rather than run them in sequence, the controller runs the element defined by the switch value.
Swtchコントローラはインタリーブコントローラと同じように振る舞います。それぞれの繰り返しの中で配下の要素の中の一つを実行させますが、順番によってではなく、実行対象で定義した値によって要素をコントローラが実行させます。

Note: In versions of JMeter after 2.3.1, the switch value can also be a name.
注意：JMeterバージョン2.3.1以降では実行対象は名前での指定も可能です。

If the switch value is out of range, it will run the zeroth element, which therefore acts as the default for the numeric case. It also runs the zeroth element if the value is the empty string.
実行対象が範囲(配下の要素の数)を越えている場合にはゼロ番目の要素として評価されるため、数字の場合のデフォルトとして振る舞います。空文字列であった場合も同様にゼロ番目の要素として評価されます。

If the value is non-numeric (and non-empty), then the Switch Controller looks for the element with the same name (case is significant). If none of the names match, then the element named "default" (case not significant) is selected. If there is no default, then no element is selected, and the controller will not run anything.
値が数字ではない（且つ空文字列ではない)場合には、Switchコントローラは同じ名前(大文字小文字の区別を行ないます)の要素を探します。同名のものが存在しない場合には、"default"という名前(大文字小文字の区別を行ないます)の要素が選択されます。defaultが存在しない場合には要素は何も選択されず、コントローラは何も実行しません。

Control Panel

Parameters
Attribute    Description    Required
Name     Descriptive name for this controller that is shown in the tree, and used to name the transaction.     Yes
名前    ツリー上に表示されるコントローラの名前と、トランザクションで使用される名前。

Switch Value     The number (or name) of the subordinate element to be invoked. Elements are numbered from 0.     Yes
実行対象    実行対象とする配下の要素の番号(又は名前)。配下の要素は0あkら番号付けられる。

18.2.12 ForEach Controller
18.2.12 ForEachコントローラ

A ForEach controller loops through the values of a set of related variables. When you add samplers (or controllers) to a ForEach controller, every sample sample (or controller) is executed one or more times, where during every loop the variable has a new value. The input should consist of several variables, each extended with an underscore and a number. Each such variable must have a value. So for example when the input variable has the name inputVar, the following variables should have been defined:
ForEachコントローラは関連する１セットの変数を通じてループします。ForEachコントローラにサンプラ(もしくはコントローラ)を追加する場合、全てのサンプル(訳注：sampleの重複)(もしくはコントローラ)は一度以上実行され、全てのループの中で変数はそれぞれ異なる値を使用します。そのようなそれぞれの変数は値を持っている必要があります。例として入力変数の名前を inputVar とし、以下の変数が定義されているものとします。

    * inputVar_1 = wendy
    * inputVar_2 = ch
439484 journal

bananan_wの日記： 英語勉強日記#11(翻訳がんばろう日記)

日記 by bananan_w
17章。

17. Help! My boss wants me to load test our web app!
17. 助けて!上司にウェブアプリケーションの負荷試験を行うように指示されました!

    This is a fairly open-ended proposition. There are a number of questions to be asked first, and additionally a number of resources that will be needed. You will need some hardware to run the benchmarks/load-tests from. A number of tools will prove useful. There are a number of products to consider. And finally, why is Java a good choice to implement a load-testing/Benchmarking product.
    これは実に制限の存在しない議題です。初めに確認する多数の質問があり、どれだけのリソースが必要とされているか。また、ベンチマークや負荷テストを実施するにはいくつかのハードウェアが必要になるでしょう。いくつかのプロダクトに別れている、いくつもの便利なツールの存在に気がつくでしょう。そして最終的には、負荷テストやベンチマークプロダクトの実装の選択に何故Javaが優れた選択であるのかを理解するでしょう。

    17.1 Questions to ask
    17.1 質問と回答

        What is our anticipated average number of users (normal load) ?
        予想されるユーザの平均数はいくつでしょうか(平常負荷)？

        What is our anticipated peak number of users ?
        予想される最大ユーザ数はいくつでしょうか？

        When is a good time to load-test our application (i.e. off-hours or week-ends), bearing in mind that this may very well crash one or more of our servers ?
        アプリケーションに負荷を掛けるのに適切な時間(例えば、休みの時間か週末)はいつですか。これはサーバのクラッシュを頻繁に引き起こす事を心に留めておいてください。

        Does our application have state ? If so, how does our application manage it (cookies, session-rewriting, or some other method) ?
        アプリケーションは状態を保持しますか？保持するのならアプリケーションはどのようにして状態を管理していますか(クッキー、セッションリライト、又は他の方法)？

        What is the testing intended to achieve?
        テストを実施する代わりにアーカイブを参照できませんか？

    17.2 Resources
    17.2 リソース

        The following resources will prove very helpful. Bear in mind that if you cannot locate these resources, you will become these resources. As you already have your work cut out for you, it is worth knowing who the following people are, so that you can ask them for help if you need it.
        以下のリソースは大変役に立っていると判断できるでしょう。それらのリソースが存在しない場合には、これらのリソースになる事を忘れないでください(約注:意味不明。。。)。既に仕事が開始されている場合には、以下の人のうち誰がどの仕事を行っているか把握する必要があります。必要に応じて彼らに問い合わせを行うことは手助けとなるでしょう。

        17.2.1 Network
        17.2.1 ネットワーク

            Who knows our network topology ? If you run into any firewall or proxy issues, this will become very important. As well, a private testing network (which will therefore have very low network latency) would be a very nice thing. Knowing who can set one up for you (if you feel that this is necessary) will be very useful. If the application doesn't scale as expected, who can add additional hardware ?
             ネットワークとポロジを誰が把握していますか？ネットワークかプロキシのいずれかを経由して試験を実施する場合、これは大変重要なことです。テスト用の特別なネットワーク(それゆえにネットワークレイテンシが大変低いでしょう)では良好な成果を得るでしょう。誰が上記を設定できるか(これが重要だと考えているなら)知っているならとても便利でしょう。アプリケーションの性能が望んだ水準に達しない場合には、誰がハードウェアを追加できますか？

        17.2.2 Application
        17.2.2 アプリケーション

            Who knows how our application functions ? The normal sequence is
            アプリケーションの機能を誰が把握していますか？通常は以下の通りです。

                * test (low-volume - can we benchmark our application?)
                * benchmark (the average number of users)
                * load-test (the maximum number of users)
                * test destructively (what is our hard limit?)
                * テスト(小規模 - アプリケーションのベンチマークを実施できるか？)
                * ベンチマーク(平均ユーザ数)
                * 負荷試験(最大ユーザ数)
                * 破壊的テスト(ハードウェアの限界の調査)

            The test process may progress from black-box testing to white-box testing (the difference is that the first requires no knowledge of the application [it is treated as a "black box"] while the second requires some knowledge of the application). It is not uncommon to discover problems with the application during this process, so be prepared to defend your work.
             テスト過程はブラックボックステストからホワイトボックステストへ前進する(異なる点はアプリケーションの初めのリクエストに対する知識はありません["ブラックボックス"の様に処理された]が、二つ目のリクエストはいくつかのアプリケーションに対する知識があることです)様なものです。この過程ではアプリケーションの問題を発見することは良くあり、仕事の一つとして事前に組み込まれているべきです。

17.3 What platform should I use to run the benchmarks/load-tests ?
17.3 ベンチマークや負荷試験をどのプラットフォームで実施すべきですか？

    This should be a widely-used piece of hardware, with a standard (i.e. vanilla) software installation. Remember, if you publish your results, the first thing your clients will do is hire a graduate student to verify them. You might as well make it as easy for this person as you possibly can.
    これはハードウェアに強く依存し、標準的な(吊しの)ソフトウェアをインストールするべきです。テスト結果を公表する場合、クライアントが最初にすることは大学院生を雇って検証することです。これをより簡単に実施させることが望ましいです。

    For Windows, Windows XP Professional should be a minimum (the others do not multi-thread past 50-60 connections, and you probably anticipate more users than that).
    Windowsでは、Windows XP Professionalが最小要求です(それ以外はマルチスレッドで50-60接続ユーザを越える接続を処理しきれないでしょう)。

    Good free platforms include the linuxes, the BSDs, and Solaris Intel. If you have a little more money, there are commercial linuxes. If you can justify it, a commercial Unix (Solaris, etc) is probably the best choice.
    優秀な無料のプラットフォームにはLinux、BSD一族、Intel Solarisがあります。もし小金持ちであるなら、商用Linuxも存在します。それらに納得できない場合には、商用Unix(Solaris、その他)がおそらく最善の選択となります。

    For non-Windows platforms, investigate "ulimit -n unlimited" with a view to including it in your user account startup scripts (.bashrc or .cshrc scripts for the testing account).
    Windows以外のプラットフォームにおいて、"ulimit -n unlimited"をユーザアカウントのスタートアップスクリプトに含めるかどうか吟味してください(テスト実施アカウントの.bashrcか.cshrcスクリプトにおいて)。

    As you progress to larger-scale benchmarks/load-tests, this platform will become the limiting factor. So it's worth using the best hardware and software that you have available. Remember to include the hardware/software configuration in your published benchmarks.
    巨大なベンチマークや負荷試験を進める場合には、これらのプラットフォームでは性能のボトルネックとなります。有用な結果を得るためには最良のハードウェアとソフトウェアを使用する価値があります。ハードウェアとソフトウェアの設定も含めてベンチマーク結果を公表することを忘れないでください。

    Don't forget JMeter batch mode. This can be useful if you have a powerful server that supports Java but perhaps does not have a fast graphics implementation, or where you need to login remotely. Batch (non-GUI) mode can reduce the network traffic compared with using a remote display or client-server mode. The batch log file can then be loaded into JMeter on a workstation for analysis, or you can use CSV output and import the data into a spreadsheet.
    JMeterのバッチモードを忘れないでください。Javaをサポートする強力であるが高速なグラフィック性能をもっていない場合や、リモートログインする必要がある場合にとても便利です。バッチ(non-GUI)モードはリモートディスプレイから結果を確認したり、クライアントサーバモードで動作させるネットワークトラフィックを削減できます。バッチログファイルはワークステーションで動作するJMeterの実行結果を解析でき、また、CSV出力をさせ表計算ソフトから読み込むことができます。

17.4 Tools
17.4 ツール

    The following tools will all prove useful. It is definitely worthwhile to become familiar with them. This should include trying them out, and reading the appropriate documentation (man-pages, info-files, application --help messages, and any supplied documentation).
    いかのツールはどれも便利なものです。これらは間違いなく使いこなす価値があります。それらを十分に試すべきで、適切な文書(manページ、infoファイル、application --helpメッセージ、その他提供される文書)を読むべきです。

    17.4.1 ping
    17.4.1 ping

        This can be used to establish whether or not you can reach your target site. Options can be specified so that 'ping' provides the same type of route reporting as 'traceroute'.
        これはターゲットサイトに到達可能かを調査します。オプションを指定できるので'pingは'traceroute'と同様のルートレポートを提供します。

    17.4.2 nslookup/dig
    17.4.2 nslookup/dig

        While the user will normally use a human-readable internet address, you may wish to avoid the overhead of DNS lookups when performing benchmarking/load-testing. These can be used to determine the unique address (dotted quad) of your target site.
        通常、ユーザは人間が読むことのできるインターネットアドレスを使用しますが、ベンチマークや負荷試験の性能からDNS検索のオーバヘッドを取り除きたいと思うかもしれません。これはユニークアドレス(ドット4つの)をターゲットサイトに指定して実現できます。

    17.4.3 traceroute
    17.4.3 traceroute

        If you cannot "ping" your target site, this may be used to determine the problem (possibly a firewall or a proxy). It can also be used to estimate the overall network latency (running locally should give the lowest possible network latency - remember that your users will be running over a possibly busy internet). Generally, the fewer hops the better.
        ターゲットサイトに"ping"が実行できない場合、これを使用すると問題（ファイアウォールかプロキシ要因のもの)を洗い出せるかもしれません。これは全てのネットワークレイテンシを計測することに使用されます(ローカルでの実行は最も低いレイテンシを得ます - ユーザは混雑しているインターネット経由でアクセスすることを忘れないでください)。通常、少ないホップ数であることが望ましいです。

17.5 What other products are there ?
17.5 他にはどのような製品がありますか？

    There are a number of commercial products, which generally have fairly hefty pricetags. If you can justify it, these are probably the way to go. If, however, these products do not do exactly what you want, or you are on a limited budget, the following are worth a look. In fact, you should probably start by trying the Apache ab tool, as it may very well do the job if your requirements are not particularly complicated.
    いくつもの商用製品があり、かなり高額な値札が通常付けられています。それについて納得できるなら購入するといいでしょう。ですが、それらの製品が望んだ機能を実装していない場合や、予算の制限が存在する場合には、以下は見る価値があります。実際には、要求は複雑で入り組んだものではないことが多いため、Apache abツールの様なものを試すことで要求は満たされるでしょう。

    17.5.1 Apache 'ab' tool
    17.5.1 Apache 'ab'ツール

        You should definitely start with this one. It handles HTTP 'get' requests very well, and can be made to handle HTTP 'post' requests with a little effort. Written in 'C', it performs very well, and offers good (if basic) performance reporting.
        確実にこれから取り掛かるべきです。これはHTTPの'get'リクエストを確実に処理し、HTTP 'post'リクエストを多少の努力で確実に処理できます。'C'で書かれ、性能は非常に高く、優秀な(基本的で構わないなら)性能レポートを提供します。

    17.5.2 HttpUnit
    17.5.2 HttpUnit

        This is worth a look. It is a library (and therefore of more interest to developers) that can be used to perform HTTP tests/benchmarks. It is intended to be used instead of a web browser (therefore no GUI) in conjunction with JUnit .
        これは見る価値があります。これはライブラリ(従って開発者により関心をもたれます)でHTTPテストやベンチマークを実施できます。JUnitと連係してウェブブラウザの代わりになることを意図しています(従ってGUIを持ちません)。

    17.5.3 Microsoft WAS
    17.5.3 Microsoft WAS

        This is definitely worth a look. It has an excellent user interface but it may not do exactly what you want. If this is the case, be aware that the functionality of this product is not likely to change.
        これは間違いなく見る価値があります。華麗なユーザインタフェースを持ちますが、望む機能はおそらく持っていないでしょう。この場合には、この製品の機能は変更されないことを認識してください。

    17.5.4 JMeter
    17.5.4 JMeter

        If you have non-standard requirements, then this solution offers an open-source community to provide them (of course, if you are reading this , you are probably already committed to this one). This product is free to evolve along with your requirements.
        非標準的な要求がある場合には、オープンソースコミュニティによって提供されるJMeterが解決方法を提示します(もちろん、このドキュメントを読んでいるなら、既にJMeterを選択しているはずです)。このプロダクトはあなたの要求とともに自由に発展します。

17.6 Why Java ?
17.6 何故Javaなの？

    Why not Perl or C ?
    何故PerlやCではないのですか？

    Well, Perl might be a very good choice except that the Benchmark package seems to give fairly fuzzy results. Also, simulating multiple users with Perl is a tricky proposition (multiple connections can be simulated by forking many processes from a shell script, but these will not be threads, they will be processes). However, the Perl community is very large. If you find that someone has already written something that seems useful, this could be a very good solution.
    Benchmarkパッケージがかなり不明瞭な結果を返すこと以外はPerlを選択することはとても良い選択です。複数ユーザをPerlでシミュレートするには厄介な手段(シェルスクリプトから複数のプロセスをフォークして複数の接続をシミュレートすることは、スレッドではなくプロセスです)が必要です。しかしながら、Perlコミュニティは非常に巨大です。もし誰かが既に便利なものを作成しているなら、それは良い手段と言えます。

    C, of course, is a very good choice (check out the Apache ab tool). But be prepared to write all of the custom networking, threading, and state management code that you will need to benchmark your application.
    Cはもちろんとても良い選択です(Apache abツールに見られる通り)。しかしベンチマークアプリケーションに関するネットワーク、スレッド、状態管理の全てのコードを記述して準備しなければなりません。

    Java gives you (for free) the custom networking, threading, and state management code that you will need to benchmark your application. Java is aware of HTTP, FTP, and HTTPS - as well as RMI, IIOP, and JDBC (not to mention cookies, URL-encoding, and URL-rewriting). In addition Java gives you automatic garbage-collection, and byte-code level security.
    ベンチマークアプリケーションで必要になる(無料の)ネットワーク、スレッド、状態管理コードがJavaには存在します。JavaはHTTP、FTP、HTTPSに関する処理方式を組み込まれています - また、RMI、IIOP、JDBC(クッキー、URLエンコーディング、URLリライティングに関しては除きます)も同じく組み込まれています。更にJavaは自動ガベージコレクションとバイトコードレベルのセキュリティを提供します。

    And once Microsoft moves to a CLR (common language run-time) a Windows Java solution will not be any slower than any other type of solution on the Windows platform.
    MicrosoftがWindowsのJavaソリューションをCLR(common language run-time)へ移行させると、その他のWindowsプラットフォーム上のソリューションより遅くなることはなくなるでしょう。
457272 journal

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.
457282 journal

bananan_wの日記： 英語勉強日記#9(翻訳がんばろう日記)

日記 by bananan_w
15章。週末中に18章着手目指してがんがりましょう。

15. Remote Testing
15. リモートテスト

    In the event that your JMeter client machine is unable, performance-wise, to simulate enough users to stress your server, an option exists to control multiple, remote JMeter engines from a single JMeter GUI client. By running JMeter remotely, you can replicate a test across many low-end computers and thus simulate a larger load on the server. One instance of the JMeter GUI client can control any number of remote JMeter instances, and collect all the data from them. This offers the following features:
    JMeterクライアントマシンが性能的に、付加をシミュレートするためのユーザが十分ではない等により使用できない場合には、複数のJMeterを制御するためのオプションが存在し、リモートのJMeterを一つのJMeter GUIクライアントから操作できます。リモートからJMeterを動作させることにより沢山の安価なコンピュータにテストを複製して、サーバに対する巨大な付加をシミュレートできます。JMeter GUIクライアントの一つのインスタンスがリモートの複数のJMeterインスタンスの制御と、全てのデータを収集できます。これは以下を実現します。

         * Saving of test samples to a local machine
         * テストサンプルをローカルマシンに保存します

       * Managment of multiple JMeterEngines from a single machine
       * 一台のマシンで複数のJMeterを管理運用します

    However, remote mode does use more resources than running the same number of non-GUI tests independently.
    しかしながら、リモートモードは独立して同じ数のnon-GUIテストを独立して実施するよりも多くのリソースを使用します。

    Note that while you can indeed execute the JMeterEngine on your application server, you need to be mindful of the fact that this will be adding processing overhead on the application server and thus your testing results will be somewhat tainted. The recommended approach is to have one or more machines on the same Ethernet segment as your application server that you configure to run the JMeter Engine. This will minimize the impact of the network on the test results without impacting the performance of the application serer itself.
    アプリケーションサーバに実際にJMeterによって負荷をかけている際には、アプリケーションサーバのテスト結果は追加する処理によって生じるオーバヘッドのため多少不正確となることに注意してください。アプリケーションサーバと同一のイーサネットセグメントに付加をかけるJMeterを複数用意することが望ましい手法です。ネットワークによる影響を最小化し、ネットワークに影響されないアプリケーションサーバの性能のテスト結果を得られます。

    Step 1: Start the servers
    Step 1: サーバを起動する

    To run JMeter in remote node, start the JMeter server component on all machines you wish to run on by running the JMETER_HOME/bin/jmeter-server (unix) or JMETER_HOME/bin/jmeter-server.bat (windows) script.
    リモートノードでJMeterを実行するには、実行させたい全てのマシン上でJMeterサーバコンポーネントをJMETER_HOME/bin/jmeter-server (unix) か JMETER_HOME/bin/jmeter-server.bat (windows)スクリプトによって起動させます。

    Note that there can only be one JMeter server on each node unless different RMI ports are used.
    異なるRMIポートを使用する場合を除いて、一台のノードで実行できるJMeterサーバの数は一つだけであることに注意してください。

    Since JMeter 2.3.1, the JMeter server application starts the RMI registry itself; there is no need to start RMI registry separately. To revert to the previous behaviour, define the JMeter property server.rmi.create=false on the server host systems.
    JMeter 2.3.1 以降ではJMeterサーバアプリケーションはRMIレジストリに自分で登録します。これはRMIレジストリを別途開始させる必要がないことを意味します。2.3.1より前の状態に戻すには、サーバホストシステムにJMeterプロパティserver.rmi.create=falseを定義します。

    Step 2: Add the server IP to your client's Properties File
    Step 2: クライアントのプロパティファイルにサーバのIPアドレスを追加する

    Edit the properties file on the controlling JMeter machine . In /bin/jmeter.properties, find the property named, "remote_hosts", and add the value of your running JMeter server's IP address. Multiple such servers can be added, comma-delimited.
    制御するJMeterマシンのプロパティファイルを編集します。bin/jmeter.properties(訳注:/binじゃないよ)にプロパティ名"remote_hosts"にJMeterサーバのIPアドレスを追記します。複数のサーバを登録する場合にはカンマ区切で登録します。

    Note that you can use the -R command line option instead to specify the remote host(s) to use. This has the same effect as using -r and -Jremote_hosts={serverlist}. E.g. jmeter -Rhost1,127.0.0.1,host2
    コマンドラインで-Rオプションを使用することでリモートホストを指示できることに注意してください。これは-r -Jremote_hosts={serverlist}と等価です。例: jmeter -Rhost1,127.0.0.1,host2

    If you define the JMeter property server.exitaftertest=true, then the server will exit after it runs a single test. See also the -X flag (described below)
    JMeterプロパティserver.exitaftertest=trueが定義されている場合、一度のテストを完了した後にサーバは終了します。-Xフラグについて参照してください(後に記します)。

    Step 3a: Start the JMeter Client from a GUI client
    Step 3a: GUIクライアントからJMeterクライアントを開始させる

    Now you are ready to start the controlling JMeter client. For MS-Windows, start the client with the script "bin/jmeter.bat". For UNIX, use the script "bin/jmeter". You will notice that the Run menu contains two new sub-menus: "Remote Start" and "Remote Stop" (see figure 1). These menus contain the client that you set in the properties file. Use the remote start and stop instead of the normal JMeter start and stop menu items.
    管理するためのJMeterクライアントを起動させる準備が整いました。MS-Windowsである場合には"bin/jmeter.bat"、UNIXである場合には"bin/jmeter"スクリプトを使用します。実行メニューに二つの新しいサブメニュー"開始(リモート)"と"停止(リモート)"の存在に気がつくでしょう(図1を参照してください)(訳注:図15-1じゃないの？)。

    Figure 1 - Run Menu
    図1 - 実行メニュー(訳注:図15-1では？)

    Step 3b: Start the JMeter from a non-GUI Client
    Step 3b: JMeterをnon-GUIクライアントで起動させる

    As an alternative, you can start the remote server(s) from a non-GUI (command-line) client. The command to do this is:
    他の手段として、リモートサーバをnon-GUI(コマンドライン)クライアントとして起動できます。コマンドは以下の通りです:

    jmeter -n -t script.jmx -r
    or
    又は
    jmeter -n -t script.jmx -R server1,server2...

    Other flags that may be useful:
    他に以下のフラグが便利です:

    -Gproperty=value - define a property in all the servers (may appear more than once)
    -Gproperty=value - 全てのサーバにプロパティを定義します(複数回出現します)

    -Z - Exit remote servers at the end of the test.
    -Z - テスト終了時にリモートサーバを終了させます

    The first example will start whatever servers are defined in the JMeter property remote_hosts; the second example will define remote_hosts from the list of servers and then run the remote servers.
    The command-line client will exit when all the remote servers have stopped.
    一つ目の例はJMeterプロパティremote_hostsに登録されている全てのサーバを起動します。二つ目の例はremote_hostsをサーバの一覧で定義してリモートサーバを起動します。
    コマンドラインクライアントは全てのリモートサーバが停止した後に終了します。

    15.1 Doing it Manually
    15.1 手動で起動する

        In some cases, the jmeter-server script may not work for you (if you are using an OS platform not anticipated by the JMeter developers). Here is how to start the JMeter servers (step 1 above) with a more manual process:
        いくつかのケースで、jmeter-serverスクリプトが動作しない(JMeter開発者が予期していないOSプラットフォームを使用している場合)かもしれません。これはJMeterサーバを手動で起動する手順(上記のStep 1)です。

        Step 1a: Start the RMI Registry
        Step 1a: RMIレジストリを起動させる

        Since JMeter 2.3.1, the RMI registry is started by the JMeter server, so this section does not apply in the normal case. To revert to the previous behaviour, define the JMeter property server.rmi.create=false on the server host systems and follow the instructions below.
        JMeter 2.3.1 からJMeterサーバによってRMIレジストリが開始されますが、このセクションは正常ではないケースを想定しています。JMeter 2.3.1 より前の状態にするため、JMeterプロパティserver.rmi.create=falseをサーバホストシステムに定義し、以下の指示に従ってください。

        JMeter uses Remote Method Invocation (RMI) as the remote communication mechanism. Therefore, you need to run the RMI Registry application (which is named, "rmiregistry") that comes with the JDK and is located in the "bin" directory. Before running rmiregistry, make sure that the following jars are in your system claspath:
        JMeterはRemote Method Invocation (RMI)を使用してリモート通信を実現しています。そのため、JDKとともに配布され"bin"ディレクトリに存在するRMIレジストリアプリケーション("rmiregistry"という名前)を起動させる必要があります。rmiregistryを起動する前に、システムクラスパスに以下のjarファイルが存在するか確認してください。

            * JMETER_HOME/lib/ext/ApacheJMeter_core.jar
            * JMETER_HOME/lib/jorphan.jar
            * JMETER_HOME/lib/logkit-1.2.jar

        The rmiregistry application needs access to certain JMeter classes. Run rmiregistry with no parameters. By default the application listens to port 1099.
        rmiregistryアプリケーションはいくつかのJMeterクラスパスにアクセスする必要があります。rmiregistryをパラメータなしで起動させると、デフォルトではアプリケーションはポート1099で待ち受けます。

        Step 1b: Start the JMeter Server
        Step 1b: JMeterサーバを起動する

        Once the RMI Registry application is running, start the JMeter Server. Use the "-s" option with the jmeter startup script ("jmeter -s").
        RMIレジストリアプリケーションを起動させた後にJMeterサーバを起動します。JMeter起動スクリプトに"-s"オプションを追加します("jmeter -s")。

        Steps 2 and 3 remain the same.
        Step 2 と Step 3は同じです。

    15.2 Tips
    15.2 ヒント

        If you're running Suse Linux, these tips may help. The default installation may enable the firewall. In that case, remote testing will not work properly. The following tips were contributed by Sergey Ten.
        Suse Linuxを使用している場合には、これらのヒントは手助けになるでしょう。インストーラのデフォルトはファイアウォールを有効にします。この場合、リモートテストは期待通りには動作しないでしょう。以下のヒントはSergey Ten氏によって寄稿されました。

        If you see connections refused, turn on debugging by passing the following options.
        connections refusedを発見した場合には、デバッグを有効にして以下のオプションを適用します。

        Since JMeter 2.3.1, the RMI registry is started by the server; however the options can still be passed in from the JMeter command line. For example: "jmeter -s -Dsun.rmi.loader.logLevel=verbose" (i.e. omit the -J prefixes). Alternatively the properties can be defined in the system.properties file.
        JMeter 2.3.1 からRIMレジストリはサーバによって起動されます。しかしながら、JMeterコマンドラインはオプションをいまだに受け付けています。例えば、"jmeter -s -Dsun.rmi.loader.logLevel=verbose"(例:-Jプレフィックスを除く)。代わりとしてプロパティにはsystem.propertiesファイルにて定義できます。

        The solution to the problem is to remove the loopbacks 127.0.0.1 and 127.0.0.2 from etc/hosts. What happens is jmeter-server can't connect to rmiregistry if 127.0.0.2 loopback is not available. Use the following settings to fix the problem.
        問題の解決方法はループバックである127.0.0.1と127.0.0.2を/etc/hostsから削除することです。ループバック127.0.0.2が無効である場合には、JMeterサーバがrmiregistryに接続できない状況が発生します。以下の設定を使用することで問題を回避できます。

        Replace
        以下を置換します

            * `dirname $0`/jmeter -s "$@"

        With
        次のように

            * HOST="-Djava.rmi.server.hostname=[computer_name][computer_domain]
            * -Djava.security.policy=`dirname $0`/[policy_file]"
            * `dirname $0`/jmeter $HOST -s "$@"

        Also create a policy file and add [computer_name][computer_domain] line to /etc/hosts.
        ポリシーファイルを作成し、[computer_name][computer_domain]の行を/etc/hostsに追加します。

    15.3 Using a different port
    15.3 異なるポートを使用する

        By default, JMeter uses the standard RMI port 1099. It is possible to change this. For this to work successfully, all the following need to agree:
        デフォルトではJMeterは標準RMIポートに1099を使用します。これは変更することができます。変更する場合には、以下の全てを一致させる必要があります。

            * On the server, start rmiregistry using the new port number
            * On the server, start JMeter with the property server_port defined
            * On the client, update the remote_hosts property to include the new remote host:port settings
            * サーバ上において、rmiregistryを新しいポート番号で起動させる
            * サーバ上において、プロパティserver_portを定義する
            * クライアント上において、プロパティremote_hostsに新しいhost:port設定を含ませる

        Since Jmeter 2.1.1, the jmeter-server scripts provide support for changing the port. For example, assume you want to use port 1664 (perhaps 1099 is already used).
        JMeter 2.1.1 からは、ポート番号の変更をサポートしたjmeter-serverスクリプトを同梱しています。例えば、ポート1664を使用したいと仮定します(もし1099を既に使用している場合)。

        On Windows (in a DOS box)
        Windows上 (DOS窓で)
        C:\JMETER> SET SERVER_PORT=1664
        C:\JMETER> JMETER-SERVER [other options]

        On Unix:
        Unix上:
        $ SERVER_PORT=1664 jmeter-server [other options]
        [N.B. use upper case for the environment variable]
        [上のケースでは環境変数を使用します]

        In both cases, the script starts rmiregistry on the specified port, and then starts JMeter in server mode, having defined the "server_port" property.
        両方のケースにおいて、スクリプトはrmiregistryを指定したポート番号で起動させ、JMeterをサーバモードで起動させ、"server_port"プロパティを定義します。

        The chosen port will be logged in the server jmeter.log file (rmiregistry does not create a log file).
        選択したポート番号はサーバのjmeter.logファイルに出力されます(rmiregistryはログを出力しません)。

    15.4 Using sample batching
    15.4 サンプルバッチ処理を実行する

        Listeners in the test plan send their results back to the client JMeter which writes the results to the specified files By default, samples are sent back as they are generated. This can place a large load on the network and the JMeter client. There are some JMeter properties that can be set to alter this behaviour.
        クライアントJMeterが受信した結果をテスト計画のリスナに送信させ、指定したファイルに保存します(訳注:By defaultの前にドットが抜けてる)。デフォルトでは生成された通りにサンプルを送信します。これはJMeterクライアントとネットワークに巨大な負荷をかけます。いくつかのJMeterプロパティによってこの挙動を変更できます。

            * mode - sample sending mode - default is Standard
            * mode - サンプル送信モード - デフォルトはStandard

                  o Standard - send samples as soon as they are generated
                  o Standard - サンプルが生成されるや否や送信します。

                  o Hold - hold samples in an array until the end of a run. This may use a lot of memory on the server.
                  o Hold - テストが完了するまで配列に保持する。サーバ上に大量のメモリが必要となるかもしれません。

                  o Batch - send saved samples when either the count or time exceeds a threshold
                  o Batch - 回数か指定の時間を経過した場合に保存したサンプルを送信します。

                  o Statistical - send a summary sample when either the count or time exceeds a threshold. The samples are summarised by thread group name and sample label. The following fields are accumulated:
                  o Statistical - 回数か指定の時間を経過した場合にサンプルの要約を送信します。サンプルはスレッドグループ名とサンプルラベルで要約を作ります。以下の項目が蓄積されます:

                        + elapsed time
                        + latency
                        + bytes
                        + sample count
                        + error count
                        + 経過時間
                        + レイテンシ
                        + バイト長
                        + サンプル数
                        + エラー数

                    Other fields that vary between samples are lost.
                    他のサンプルに関する項目は失われます。

        The following properties apply to the Batch and Statistical modes:
        以下のプロパティはBatchとStatisticalモードで適用されます:

            * num_sample_threshold - number of samples in a batch (default 100)
            * time_threshold - number of milliseconds to wait (default 60 seconds)
            * num_sample_threshold - サンプルをバッチ処理する数(デフォルトは100)
            * time_threshold - ミリ秒単位の待機する時間(デフォルトは60秒)
431095 journal

bananan_wの日記： 英語勉強日記#8(翻訳がんばろう日記)

日記 by bananan_w
7章〜13章までざーっと読んでみたけど、やっぱり需要があるともあんまり思えないんで、パス。
というわけで次は14章。18章まであと少し（ひぃ

14. Introduction to listeners
14. リスナの手引き

    A listener is a component that shows the results of the samples. The results can be shown in a tree, tables, graphs or simply written to a log file. To view the contents of a response from any given sampler, add either of the Listeners "View Results Tree" or "View Results in table" to a test plan. To view the response time graphically, add graph results, spline results or distribution graph. The listeners section of the components page has full descriptions of all the listeners.
    リスナはサンプルの結果を表示する構成要素です。結果はツリーと表とグラフへの表示、単純にログファイルへの出力に対応しています。複数のサンプルから与えられた応答の内容を見るには、"ツリーで結果を参照"か"表形式で結果を参照"のどちらかのリスナをテスト計画に追加します。応答時間をグラフで表示するにはグラフ結果を追加し、スプライン曲線がグラフに表示されるでしょう(訳注:ここものすごく超訳)。リスナ(訳注:Aタグ注意)セクションには全てのリスナに対する完全な解説が記されています。

    Different listeners display the response information in different ways. However, they all write the same raw data to the output file - if one is specified.
    それぞれのリスナは異なる方法で応答の情報を表示します。その一方、指定されていれば、リスナは同一のRAWデータをファイルに出力します。

    The "Configure" button can be used to specify which fields to write to the file, and whether to write it as CSV or XML. CSV files are much smaller than XML files, so use CSV if you are generating lots of samples.
    "設定"ボタンによってファイルに出力する項目の決定と、CSVかXML形式どちらで書き込むかを指定できます。CSVファイルはXMLファイルよりサイズが小さいため、CSVではより多くのサンプルを保存できます。

    If you only wish to record certain samples, add the Listener as a child of the sampler. Or you can use a Simple Controller to group a set of samplers, and add the Listener to that. The same filename can be used by multiple samplers - but make sure they all use the same configuration!
    特定のサンプルの保存だけを行ないたい場合には、該当するサンプラの子要素としてリスナを追加してください。もしくは、サンプラのグループにシンプルコントローラを使用し、リスナをコントローラの子要素として追加します。複数のサンプラに同一のファイル名を指定できます。しかし、同一設定となる事に気をつけてください。(訳注:最後の複数のサンプラはリスナの間違いでは？)

14.1 Default Configuration
14.1 デフォルト設定

    The default items to be saved can be defined in the jmeter.properties (or user.properties) file. The properties are used as the initial settings for the Listener Config pop-up, and are also used for the log file specified by the -l command-line flag (commonly used for non-GUI test runs).
    デフォルト設定はjmeter.properties (又は user.properties)ファイルに保存されて定義されています。プロパティはリスナの設定ポップアップの初期設定としても使用され、ログファイルに-lコマンドラインオプションでログ出力先ファイルを指定できます(通常non-GUIモードでのテスト実行で使用されます)。

    To change the default format, find the following line in jmeter.properties:
    デフォルト形式を変更するには、jmeter.propertiesの次の行を変更します:

    jmeter.save.saveservice.output_format=

    The information to be saved is configurable. For maximum information, choose "xml" as the format and specify "Functional Test Mode" on the Test Plan element. If this box is not checked, the default saved data includes a time stamp (the number of milliseconds since midnight, January 1, 1970 UTC), the data type, the thread name, the label, the response time, message, and code, and a success indicator. If checked, all information, including the full response data will be logged.
    何を保存するかという情報はここで設定できます。最大値情報、"xml"形式で保存するか、テスト計画要素で"Functional Test Mode"を指定するか等が設定できます。このチェックボックスを有効にしない場合、デフォルトの設定が適用されます。デフォルトはタイムスタンプ(UTC 1970/01/01 00:00:00から現在時刻までのミリ秒単位の経過時間)、データタイプ、スレッド名、ラベル、レスポンス時間(訳注:save latencyのこと？)、メッセージ、ステータスコード、success indicator(訳注:Save Assertion Failure Message(アサーションの失敗メッセージじゃないの？)です。すべての項目をチェックした場合には応答データのすべての情報がログに出力されます。

    The following example indicates how to set properties to get a vertical bar ("|") delimited format that will output results like:.
    以下の例では縦棒("|")を区切子とした形式でプロパティを設定し、出力される例を示しています。

timeStamp|time|label|responseCode|threadName|dataType|success|failureMessage
02/06/03 08:21:42|1187|Home|200|Thread Group-1|text|true|
02/06/03 08:21:42|47|Login|200|Thread Group-1|text|false|Test Failed:
    expected to contain: password etc.

    The corresponding jmeter.properties that need to be set are shown below. One oddity in this example is that the output_format is set to csv, which typically indicates comma-separated values. However, the default_delimiter was set to be a vertical bar instead of a comma, so the csv tag is a misnomer in this case. (Think of CSV as meaning character separated values)
    設定する必要があるjmeter.propertiesの項目は以下の通りです。この例で一つだけ特異な点はoutput_formatがcsvに設定されており、これは通常カンマ区切りを指示します。しかし、default_delimiterにはカンマではなく縦棒が指定されているため、この場合にはcsv区切りは異なったものとなります。(CSV形式を期待しているが、異なる区切子で分割されるため)

jmeter.save.saveservice.output_format=csv
jmeter.save.saveservice.assertion_results_failure_message=true
jmeter.save.saveservice.default_delimiter=|

    The full set of properties that affect result file output is shown below.
    ファイル出力に影響を与えるプロパティの一式は以下の通りです。

#---------------------------------------------------------------------------
# Results file configuration
#---------------------------------------------------------------------------

# This section helps determine how result data will be saved.
# The commented out values are the defaults.

# legitimate values: xml, csv, db.  Only xml and csv are currently supported.
#jmeter.save.saveservice.output_format=xml

# true when field should be saved; false otherwise

# assertion_results_failure_message only affects CSV output
#jmeter.save.saveservice.assertion_results_failure_message=false
#
#jmeter.save.saveservice.data_type=true
#jmeter.save.saveservice.label=true
#jmeter.save.saveservice.response_code=true
# response_data is not currently supported for CSV output
#jmeter.save.saveservice.response_data=false
# Save ResponseData for failed samples
#jmeter.save.saveservice.response_data.on_error=false
#jmeter.save.saveservice.response_message=true
#jmeter.save.saveservice.successful=true
#jmeter.save.saveservice.thread_name=true
#jmeter.save.saveservice.time=true
#jmeter.save.saveservice.subresults=true
#jmeter.save.saveservice.assertions=true
#jmeter.save.saveservice.latency=true
#jmeter.save.saveservice.samplerData=false
#jmeter.save.saveservice.responseHeaders=false
#jmeter.save.saveservice.requestHeaders=false
#jmeter.save.saveservice.encoding=false
#jmeter.save.saveservice.bytes=true
#jmeter.save.saveservice.url=false
#jmeter.save.saveservice.filename=false
#jmeter.save.saveservice.hostname=false
#jmeter.save.saveservice.thread_counts=false
#jmeter.save.saveservice.sample_count=false

# Timestamp format
# legitimate values: none, ms, or a format suitable for SimpleDateFormat
#jmeter.save.saveservice.timestamp_format=ms
#jmeter.save.saveservice.timestamp_format=MM/dd/yy HH:mm:ss

# Put the start time stamp in logs instead of the end
sampleresult.timestamp.start=true

# legitimate values: none, first, all
#jmeter.save.saveservice.assertion_results=none

# For use with Comma-separated value (CSV) files or other formats
# where the fields' values are separated by specified delimiters.
# Default:
#jmeter.save.saveservice.default_delimiter=,
# For TAB, since JMeter 2.3 one can use:
#jmeter.save.saveservice.default_delimiter=\t

#jmeter.save.saveservice.print_field_names=false

# Optional list of JMeter variable names whose values are to be saved in the result data files.
# Use commas to separate the names. For example:
#sample_variables=SESSION_ID,REFERENCE
# N.B. The current implementation saves the values in XML as attributes,
# so the names must be valid XML names.

# Optional xml processing instruction for line 2 of the file:
#jmeter.save.saveservice.xml_pi=<?xml-stylesheet type="text/xsl" href="sample.xsl"?>

    The date format to be used for the timestamp_format is described in SimpleDateFormat . Bear in mind that choosing a date format other than "ms" is likely to make it impossible for JMeter to interpret the value when it is read in later for viewing purposes.
    timestamp_formatで使用する日付形式はSimpleDateFormatで表されます。日付形式を選択する場合には、JMeterはプロパティを後から参照して時刻を確認するために割り込みを行うため"ミリ秒"以外を作成することは困難であることを覚えておいてください。

    14.1.1 Sample Variables
    14.1.1 サンプル変数

        Versions of JMeter after 2.3.1 allow one to use the sample_variables property to define a list of additional JMeter variables which are to be saved with each sample in the JTL files. The values are written to CSV files as additional columns, and as additional attributes in XML files. See above for an example.
        JMeter 2.3.1以降ではsample_variablesプロパティを定義して追加JMeter変数リストを定義しJTLファイルにそれぞれのサンプルを保存できます。値はCSVファイルとして、追加カラム、XMLファイルの追加属性が保存されます。後方の例を参照してください。

14.2 non-GUI (batch) test runs
14.2 non-GUI(バッチ)テストの実施

    When running in non-GUI mode, the -l flag can be used to create a top-level listener for the test run. This is in addition to any Listeners defined in the test plan. The configuration of this listener is controlled by entries in the file jmeter.properties as described in the previous section.
    non-GUIモードで実行する際に、-lオプションを使用してテスト実施時にトップレベルのリスナを使用できます。これはテスト計画で定義されたどのようなリスナでも追加します。このリスナはjmeter.propertiesファイルで完全に制御でき、直前のセクションで解説済みです。

    This feature can be used to specify different data and log files for each test run, for example:
    本機能は異なるデータとログファイルをそれぞれのテスト計画に指定できます。例:

jmeter -n -t testplan.jmx -l testplan_01.jtl -j testplan_01.log
jmeter -n -t testplan.jmx -l testplan_02.jtl -j testplan_02.log

    Note that JMeter logging messages are written to the file jmeter.log by default. This file is recreated each time, so if you want to keep the log files for each run, you will need to rename it using the -j option as above. The -j option was added in version 2.3.
    JMeterのログメッセージはデフォルトではjmeter.logファイルに出力される事に注意してください。このファイルは毎回作成され直されるため、実行する度のログファイルを保存するには、上記で示した通り-jオプションを使用してリネームする必要があります。-jオプションはversion 2.3から追加されました。

    Versions of JMeter after 2.3.1 support variables in the log file name. If the filename contains paired single-quotes, then the name is processed as a SimpleDateFormat format applied to the current date, for example: log_file='jmeter_'yyyyMMddHHmmss'.tmp' . This can be used to generate a unique name for each test run.
    JMeter Version 2.3.1以降ではログファイル名の変数をサポートしています。ファイル名に対となるシングルクォートが含まれる場合には、シングルクォートで囲まれない範囲はSimpleDateFormatとして処理され現在時刻が適用されます。例として、
log_file='jmeter_'yyyyMMddHHmmss'.tmp'が指定された場合には、テストを実行する度に重複の無いファイル名を生成します。

14.3 Resource usage
14.3 リソース使用量

    Listeners can use a lot of memory if there are a lot of samples. Most of the listeners currently keep a copy of every sample they display, apart from:
    大量のサンプルが存在するならリスナは大量のメモリを消費します。現状では多くのリスナは表示を行なうために全てのサンプルのコピーを保持しています。ただし、以下のものは保持しません。

        * Simple Data Writer
        * シンプルデータライタ

        * BeanShell Listener
        * BeanShellリスナ

        * Assertion Results
        * アサーション結果

        * Mailer Visualizer
        * メール表示機

        * Monitor Results
        * 観測結果

        * Summary Report
        * サマリ表示

    To minimise the amount of memory needed, use the Simple Data Writer, and use the CSV format.
    メモリ消費量を最小限に抑えるため、シンプルデータライタを使用してCSV形式で出力させましょう。

14.4 CSV Log format
14.4 CSVログフォーマット

    The CSV log format depends on which data items are selected in the configuration. Only the specified data items are recorded in the file. The order of appearance of columns is fixed, and is as follows:
    CSVログ形式は設定に置いてどのデータ項目が選択されたかに依存します。選択されたデータ項目だけがファイルに保存されます。カラムの出現順に出力し、以下に対応しています:

        * timeStamp - in milliseconds since 1/1/1970
        * タイムスタンプ - 1970/01/01 00:00:00からのミリ秒単位の経過時間

        * elapsed - in milliseconds
        * 経過時間 - ミリ秒単位

        * label - sampler label
        * ラベル - サンプラのラベル

        * responseCode - e.g. 200, 404
        * レスポンスコード - 例:200、404(訳注:むしろstatusCodeなんだけどなぁ。。。)

        * responseMessage - e.g. OK(訳注:むしろreasonPhraseなんだけどなぁ。。。)
        * レスポンスメッセージ -例:OK

        * threadName
        * スレッド名

        * dataType - e.g. text
        * データタイプ - 例 text

        * success - true or false
        * 結果 - 成功か失敗

        * failureMessage - if any
        * 失敗メッセージ - 存在するなら

        * bytes - number of bytes in the sample
        * バイト数 - サンプルのバイト数

        * grpThreads - number of active threads in this thread group
        * グループスレッド - スレッドグループ上でのスレッド番号

        * allThreads - total number of active threads in all groups
        * 総スレッド - 全てのスレッドグループのスレッドの総数

        * URL
        * URL

        * Filename - if Save Response to File was used
        * ファイル名 - 応答にファイル名が含まれているなら

        * latency - time to first response
        * レイテンシ - 初めの応答が返るまでの経過時間

        * encoding
        * エンコーディング

        * SampleCount - number of samples (1, unless multiple samples are aggregated)
        * サンプル数 - サンプル数(複数のサンプルが束ねられないなら1)

        * ErrorCount - number of errors (0 or 1, unless multiple samples are aggregated)
        * エラー数 - エラー数(複数のサンプルが束ねられないなら0か1)

        * Hostname where the sample was generated
        * ホスト名 - サンプルがどこで生成されたか(訳注:ハイフン抜けてる)

        * Variables, if specified
        * 変数 - 指定されているなら(訳注: ハイフンではなくカンマが指定されている)

14.5 XML Log format 2.0
14.5 XMLログ2.0形式

    The format of the original XML (2.0) is as follows (line breaks will be different):
    XML(2.0)のオリジナル形式は次の通りです(改行は異なるかもしれません):

<?xml version="1.0" encoding="UTF-8"?>
<testResults version="1.2">
<sampleResult timeStamp="1144365463297" dataType="text" threadName="Listen 1-1"
   label="HTTP Request" time="1502"
   responseMessage="OK" responseCode="200" success="true">
<sampleResult timeStamp="1144365464238" dataType="text" threadName="Listen 1-1"
    label="http://www.apache.org/style/style.css" time="171"
    responseMessage="OK" responseCode="200" success="true">
<property xml:space="preserve" name="samplerData">
GET http://www.apache.org/style/style.css
</property>
<binary>
body, td, th {
    font-size: 95%;
    font-family: Arial, Geneva, Helvetica, sans-serif;
    color: black;
    background-color: white;
}
...
</binary>
</sampleResult>
</sampleResult>
...
</testResults>

14.6 XML Log format 2.1
14.6 XMLログ2.1形式

    The format of the updated XML (2.1) is as follows (line breaks will be different):
    アップデートされたXML(2.1)形式は以下の通りです(改行は異なるかもしれません):

<?xml version="1.0" encoding="UTF-8"?>
<testResults version="1.2">

-- HTTP Sample, with nested samples

<httpSample t="1392" lt="351" ts="1144371014619" s="true"
     lb="HTTP Request" rc="200" rm="OK"
     tn="Listen 1-1" dt="text" de="iso-8859-1" by="12407">
  <httpSample t="170" lt="170" ts="1144371015471" s="true"
        lb="http://www.apache.org/style/style.css" rc="200" rm="OK"
        tn="Listen 1-1" dt="text" de="ISO-8859-1" by="1002">
    <responseHeader class="java.lang.String">HTTP/1.1 200 OK
Date: Fri, 07 Apr 2006 00:50:14 GMT
...
Content-Type: text/css
</responseHeader>
    <requestHeader class="java.lang.String">MyHeader: MyValue</requestHeader>
    <responseData class="java.lang.String">body, td, th {
    font-size: 95%;
    font-family: Arial, Geneva, Helvetica, sans-serif;
    color: black;
    background-color: white;
}
...
</responseData>
    <cookies class="java.lang.String"></cookies>
    <method class="java.lang.String">GET</method>
    <queryString class="java.lang.String"></queryString>
    <url>http://www.apache.org/style/style.css</url>
  </httpSample>
  <httpSample t="200" lt="180" ts="1144371015641" s="true"
     lb="http://www.apache.org/images/asf_logo_wide.gif"
     rc="200" rm="OK" tn="Listen 1-1" dt="bin" de="ISO-8859-1" by="5866">
    <responseHeader class="java.lang.String">HTTP/1.1 200 OK
Date: Fri, 07 Apr 2006 00:50:14 GMT
...
Content-Type: image/gif
</responseHeader>
    <requestHeader class="java.lang.String">MyHeader: MyValue</requestHeader>
    <responseData class="java.lang.String">http://www.apache.org/asf.gif</responseData>
      <responseFile class="java.lang.String">Mixed1.html</responseFile>
    <cookies class="java.lang.String"></cookies>
    <method class="java.lang.String">GET</method>
    <queryString class="java.lang.String"></queryString>
    <url>http://www.apache.org/asf.gif</url>
  </httpSample>
  <responseHeader class="java.lang.String">HTTP/1.1 200 OK
Date: Fri, 07 Apr 2006 00:50:13 GMT
...
Content-Type: text/html; charset=ISO-8859-1
</responseHeader>
  <requestHeader class="java.lang.String">MyHeader: MyValue</requestHeader>
  <responseData class="java.lang.String">
...
&lt;html&gt;
&lt;head&gt;
...
&lt;/head&gt;
&lt;body&gt;
...
&lt;/body&gt;
&lt;/html&gt;
</responseData>
  <cookies class="java.lang.String"></cookies>
  <method class="java.lang.String">GET</method>
  <queryString class="java.lang.String"></queryString>
  <url>http://www.apache.org/</url>
</httpSample>

-- nonHTTPP Sample

<sample t="0" lt="0" ts="1144372616082" s="true" lb="Example Sampler"
    rc="200" rm="OK" tn="Listen 1-1" dt="text" de="ISO-8859-1" by="10">
  <responseHeader class="java.lang.String"></responseHeader>
  <requestHeader class="java.lang.String"></requestHeader>
  <responseData class="java.lang.String">Listen 1-1</responseData>
  <responseFile class="java.lang.String">Mixed2.unknown</responseFile>
  <samplerData class="java.lang.String">ssssss</samplerData>
</sample>

</testResults>

    Note that the sample node name may be either "sample" or "httpSample".

14.7 Sample Attributes
14.7 サンプルの属性

    The sample attributes have the following meaning:
    サンプルの属性は以下のものがあります:

    Attribute     Content
    属性 内容

    by     Bytes
    by  バイト数

    de     Data encoding
    de  データエンコーディング

    dt     Data type
    dt  データタイプ

    ec     Error count (0 or 1, unless multiple samples are aggregated)
    ec  エラー数(0か1、複数のサンプラが束ねられない場合)

    hn     Hostname where the sample was generated
    hn  サンプルを生成したホスト名

    lb     Label
    lb  ラベル(訳注:サンプラのラベルって書いてほしいなぁ)

    lt     Latency = time to initial response (milliseconds) - not all samplers support this
    lt  レイテンシ = 初回応答時間(ミリ秒) - 全てのサンプラではサポートされていません

    na     Number of active threads for all thread groups
    na  すべてのスレッドグループでのスレッド数

    ng     Number of active threads in this group
    ng  スレッドグループのスレッド数

    rc     Response Code (e.g. 200)
    rc  レスポンスコード(例:200)

    rm     Response Message (e.g. OK)
    rm  レスポンスメッセージ(例:OK)

    s     Success flag (true/false)
    s   成功フラグ(true/false)

    sc     Sample count (1, unless multiple samples are aggregated)
    sc  サンプル数(1、サンプルが束ねられていない場合)

    t     Elapsed time (milliseconds)
    t   経過時間(ミリ秒)

    tn     Thread Name
    tn  スレッド名

    ts     timeStamp (milliseconds since midnight Jan 1, 1970 UTC)
    ts  タイムスタンプ(UTC 1970/01/01 00:00:00からの経過時間のミリ秒)

    varname     Value of the named variable (versions of JMeter after 2.3.1)
    varname     指定する変数の値(JMeter version 2.3.1以降でサポート)

    Versions 2.1 and 2.1.1 of JMeter saved the Response Code as "rs", but read it back expecting to find "rc". This has been corrected so that it is always saved as "rc"; either "rc" or "rs" can be read.
    Version 2.1 と 2.1.1 ではレスポンスコードは"rs"でしたが、"rc"を発見した場合には読み替えてください。これは既に修正済みで、"rs"と"rc"を読み込んだ場合には"rc"として保存されます。

    Versions of JMeter after 2.3.1 allow additional variables to be saved with the test plan. Currently, the variables are saved as additional attributes. The testplan variable name is used as the attribute name.
    JMeter version 2.3.1 以降では追加する変数をテスト計画に保存できます。現状では、変数はadditional属性と同様に保存されます。変数名testplanは属性名と同様に使用されます。

14.8 Saving response data
14.8 応答データの保存

    As shown above, the response data can be saved in the XML log file if required. However, this can make the file rather large, and the text has to be encoded so that it is still valid XML. Also, images cannot be included.
    Another solution is to use the Post-Processor Save_Responses_to_a_file . This generates a new file for each sample, and saves the file name with the sample. The file name can then be included in the sample log output. The data will be retrieved from the file if necessary when the sample log file is reloaded.
    以前に示した通り、望むのであれば応答データをXMLログファイルに保存できます。しかしながら、ファイルサイズはかなり巨大になり、有効なXMLファイルであるためにテキストはエンコードされます。また、画像は含めることができません。
    他には後処理のSave_Responses_to_a_fileを使用する方法もあります。これはそれぞれのサンプル毎にファイルを生成し、ファイル名はサンプルによって付けられます。ファイル名はサンプルのログに出力できます。データはサンプルのログファイルを再読み込みしてファイル名を検索して参照します。

14.9 Loading (reading) response data
14.9 応答データのロード(読み込み)

    To view an existing results file, you can use the File "Browse..." button to select a file. If necessary, just create a dummy testplan with the appropriate Listener in it.
    既存の結果ファイルを参照するには"参照..."ボタンを押下してファイルを選択します。必要があればダミーのテスト計画を作成して適切なリスナを設置します。

    Results can be read from XML or CSV format files. When reading from CSV results files, the header (if present) is used to determine which fields were saved. In order to interpret a header-less CSV file correctly, the appropriate JMeter properties must be set.
    XMLかCSV形式ファイルから結果を読み込みます。CSV結果ファイルを読み込む際、ヘッダ(存在するなら)によってどの項目が保存されたかを判定できます。ヘッダの存在しないCSVファイルを性格に解析するため、適切なJMeterプロパティが接待されているべきです。
457872 journal

bananan_wの日記： 英語勉強日記#7(翻訳がんばろう日記)

日記 by bananan_w
さて、1-6章と19章まで翻訳終わり。
これで一通りのテスト計画を作るために必要なJMeterの基本的な動作の概念が理解できているはず。
この先はJDBCとかFTPとかLDAPの試験とかわりかしどーでもいい点なのでザックリと飛ばして
次は13章以降にしたい感じ。18章を除けば今月中に終わるんじゃないかな？
なかなかいいペースだね。18章だけで2週間はかかる(早くて)だろうから、今年中の完成（するのか？)を
目指してまったり行きましょう。

6. Building an Advanced Web Test Plan
6. 高度なテスト計画の構築

    In this section, you will learn how to create advanced Test Plans to test a Web site.
    このセクションではウェブサイトに高度なテストを実施する方法を習得します。

    For an example of a basic Test Plan, see Building a Web Test Plan .
    基本的なテスト計画の例はウェブテスト計画の構築(訳注:Aタグ注意)を参照してください。

6.1 Handling User Sessions With URL Rewriting
6.1 URLリライトによってユーザセッションを制御

    If your web application uses URL rewriting rather than cookies to save session information, then you'll need to do a bit of extra work to test your site.
    ウェブアプリケーションがセッション情報を保持するためにクッキーではなくURLリライトを使用する場合、サイトのテストを実施するために少しだけ追加作業が必要です。

    To respond correctly to URL rewriting, JMeter needs to parse the HTML received from the server and retrieve the unique session ID. Use the appropriate HTTP URL Re-writing Modifier to accomplish this. Simply enter the name of your session ID parameter into the modifier, and it will find it and add it to each request. If the request already has a value, it will be replaced. If "Cache Session Id?" is checked, then the last found session id will be saved, and will be used if the previous HTTP sample does not contain a session id.
    URLリライトに正確に対応するには、サーバから応答されたHTMLを解析し、ユニークなセッションIDをJMeterが読み出す必要があります。適切なHTTP URLリライト変換子を使用して実現させます。単純にセッションIDパラメータを変換子に入力すると、セッションIDを発見する度にそれぞれのリクエストにIDを追加します(訳注:ここitまみれでかなり原文ヒドイです。)。リクエストが既に値を保持している場合には、その値を置換します。”セッションIDをキャッシュする"をチェックしている場合には、最後に発見したセッションIDを保持し、直前のHTTPサンプルにセッションが含まれていない場合には保持しているものを使用します。

    URL Rewriting Example
    URLリライト例

    Download this example . In Figure 1 is shown a test plan using URL rewriting. Note that the URL Re-writing modifier is added to the SimpleController, thus assuring that it will only affect requests under that SimpleController.
    この例をダウンロード(訳注:Aタグ注意)してください。図1(ここは図6.1では？)にテスト計画でURLリライトを使用する方法を示します。URLリライト変換子はシンプルコントローラに追加されており、シンプルコントローラ配下のリクエストだけに効果を保証する事に注意してください。

    Figure 1 - Test Tree
    図1(訳注:6.1であるべき。)テストツリー

    In Figure 2, we see the URL Re-writing modifier GUI, which just has a field for the user to specify the name of the session ID parameter. There is also a checkbox for indicating that the session ID should be part of the path (separated by a ";"), rather than a request parameter
    図2(訳注:6.2が望ましい)ではURLリライト変換子のGUIを示します。ここではセッションIDパラメータの名前の項目だけを指定しています。また、セッションIDがリクエストパラメータではなく、パスの一部(";"で分割される)である事を指示するためのチェックボックスが存在します。

    Figure 2 - Request parameters
    図2(訳注:6.2であるべき) - リクエストパラメータ

6.2 Using a Header Manager
6.2 ヘッダマネージャの使用

    The HTTP Header Manager lets you customize what information JMeter sends in the HTTP request header. This header includes properties like "User-Agent", "Pragma", "Referer", etc.
    HTTPヘッダマネージャによってJMeterの送信するHTTPリクエストのヘッダ情報をカスタマイズできます。このヘッダには"User-Agent"、"Pragma"、"Referer"などの属性が含まれます。

    The HTTP Header Manager , like the HTTP Cookie Manager , should probably be added at the Thread Group level, unless for some reason you wish to specify different headers for the different HTTP Request objects in your test.
    HTTPヘッダマネージャはHTTPクッキーマネージャに似て、大概スレッドグループに追加されますが、何らかの理由によってテスト中の他のHTTPリクエストとは事なるヘッダを指定したい場合にも使用します。
66305 journal

bananan_wの日記： 用語集

日記 by bananan_w
申し送り事項
18.2.3翻訳抜け。やること。

以下悩み事項
sample results と Response Data をほぼ同義で使用されて困る。統一しようよ。
統一するとして、適切な訳語は何がいいか？サンプル結果じゃ意味わかんないし、応答電文？いっそサンプル結果に統一しちゃうか？

以下用語対応一覧
Attribute    属性
Content    内容
Config Element    設定要素
Configration Element    設定要素
Add    追加
HTTP Request Default    HTTPリクエストデフォルト
Test Plan    テスト計画
Thread Group    スレッドグループ
HTTP Cookie Manager    HTTPクッキーマネージャ
HTTP Request    HTTPリクエスト
Sampler    サンプラ
sample    サンプル
Listener    リスナ
Assertion    アサーション
Timer    タイマ
Graph Results    グラフ結果
Graph Results listener    グラフ結果リスナ
Browse button    参照ボタン
JMeter Proxy Recorder    JMeterプロキシレコーダ
URL Rewriting    URLリライト
HTTP URL Re-writing Modifier    HTTP URLリライト変換子
Cache Session Id?    セッションIDをキャッシュする
SimpleController    シンプルコントローラ
HTTP Header Manager     HTTPヘッダマネージャ
View Results Tree    ツリーで結果を参照
View Results in table    表形式で結果を参照
graph results    グラフ結果
non-GUI mode    non-GUIモード※仮称
vertical bar     縦棒
Simple Data Writer    シンプルデータライタ
BeanShell Listener    BeanShellリスナ
Assertion Results    アサーション結果
Mailer Visualizer    メール表示機
Monitor Results    観測結果
Summary Report    サマリ表示
timeStamp    タイムスタンプ
elapsed    経過時間
label    ラベル
responseCode    レスポンスコード
responseMessage    レスポンスメッセージ
threadName    スレッド名
dataType    データタイプ
success    結果
failureMessage    失敗メッセージ
bytes    バイト数
grpThreads    グループスレッド
allThreads    総スレッド
Filename    ファイル名
latency    レイテンシ
SampleCount    サンプル数
ErrorCount    エラー数
Hostname    ホスト名
response data    応答データ
proxy server    プロキシサーバ
Recording Controller    レコーディングコントローラ
load test    負荷試験(×負荷テスト)
load-test    負荷試験(×負荷テスト)
load testing    負荷試験(×負荷テスト)
HTTP Request    HTTPリクエスト
HTTP Request HTTPClient    HTTPリクエストHTTPClient
AJP/1.3 Sampler    APJ/1.3サンプラ
response    レスポンス
Embedded URL    組み込みURL（※HTMLの中に入ってる参照とかしているリソースの事らしい)
Interleave Controller    インタリーブコントローラ
regular expression extractor    正規表現抽出機

セクション対応一覧
5. Building a Web Test Plan    5. ウェブテスト計画の構築
5.1 Adding Users    5.1 ユーザの追加
5.2 Adding Default HTTP Request Properties    5.2 HTTPリクエストデフォルトプロパティを追加
5.3 Adding Cookie Support    5.3 クッキーサポートの追加
5.4 Adding HTTP Requests    5.4 HTTPリクエストを追加
5.5 Adding a Listener to View Store the Test Results    5.5 テスト結果を参照と保存するためにリスナを追加
5.6 Logging in to a web-site    5.6 ウェブサイトへのログイン
6. Building an Advanced Web Test Plan    6. 高度なテスト計画の構築
6.1 Handling User Sessions With URL Rewriting    6.1 URLリライトによってユーザセッションを制御
6.2 Using a Header Manager    6.2 ヘッダマネージャの使用
14. Introduction to listeners    14. リスナの手引き
14.1 Default Configuration    14.1 デフォルト設定
14.1.1 Sample Variables    14.1.1 サンプル変数
14.2 non-GUI (batch) test runs    14.2 non-GUI(バッチ)テストの実施
14.3 Resource usage    14.3 リソース使用量
14.4 CSV Log format    14.4 CSVログ形式
14.5 XML Log format 2.0    14.5 XMLログ2.0形式
14.6 XML Log format 2.1    14.6 XMLログ2.1形式
14.7 Sample Attributes    14.7 サンプルの属性
14.8 Saving response data    14.8 応答データの保存
14.9 Loading (reading) response data    14.9 応答データのロード(読み込み)
15. Remote Testing    15. リモートテスト
15.1 Doing it Manually    15.1 手動で起動する
15.2 Tips    15.2 ヒント
15.3 Using a different port    15.3 異なるポートを使用する
15.4 Using sample batching    15.4 サンプルバッチ処理を実行する
16. Best Practices    16. 成功事例
16.1 Limit the Number of Threads    16.1 スレッド数の制限値
16.2 Where to Put the Cookie Manager    16.2 クッキーマネージャをどこに設置するか
16.3 Where to Put the Authorization Manager    16.3 認証マネージャをどこに設置するか
16.4 Using the Proxy Server    16.4 プロキシサーバを使用する
16.5 User variables    16.5 ユーザ変数
16.6 Reducing resource requirements    16.6 リソースの要求を軽減する
16.7 BeanShell server    16.7 BeanShell server
16.8 BeanShell scripting    16.8 BeanShell scripting
16.8.1 Overview    16.8.1 Overview
16.8.2 Sharing Variables    16.8.2 Sharing Variables
17. Help! My boss wants me to load test our web app!    17. 助けて!上司にウェブアプリケーションの負荷試験を行うように指示されました!
17.1 Questions to ask    17.1 質問と回答
17.2 Resources    17.2 リソース
17.2.1 Network    17.2.1 ネットワーク
17.2.2 Application    17.2.2 アプリケーション
17.3 What platform should I use to run the benchmarks/load-tests ?    17.3 ベンチマークや負荷試験をどのプラットフォームで実施すべきですか？
17.4 Tools    17.4 ツール
17.4.1 ping    17.4.1 ping
17.4.2 nslookup/dig    17.4.2 nslookup/dig
17.4.3 traceroute    17.4.3 traceroute
17.5 What other products are there ?    17.5 他にはどのような製品がありますか？
17.5.1 Apache 'ab' tool    17.5.1 Apache 'ab'ツール
17.5.2 HttpUnit    17.5.2 HttpUnit
17.5.3 Microsoft WAS    17.5.3 Microsoft WAS
17.5.4 JMeter    17.5.4 JMeter
17.6 Why Java ?    17.6 何故Javaなの？
18.1 Samplers    18.1 サンプラ
18.1.1 FTP Request    18.1.1 FTPリクエスト
18.1.2 HTTP Request    18.1.2 HTTPリクエスト
18.2 Logic Controllers    18.2 ロジックコントローラ
18.2.1 Simple Controller    18.2.1 シンプルコントローラ
18.2.2 Loop Controller    18.2.2 ループコントローラ
18.2.4 Interleave Controller    18.2.4 インタリーブコントローラ
18.2.5 Random Controller    18.2.5 ランダムコントローラ
18.2.7 Throughput Controller    18.2.7 スループットコントローラ
18.2.8 Runtime Controller    18.2.8 実行時間コントローラ
18.2.9 If Controller    18.2.9 Ifコントローラ
18.2.10 While Controller    18.2.10 Whileコントローラ
18.2.11 Switch Controller    18.2.11 Switchコントローラ
18.2.12 ForEach Controller    18.2.12 ForEachコントローラ
18.2.13 Module Controller    18.2.13 モジュールコントローラ
18.2.14 Include Controller    18.2.14 インクルードコントローラ

その他項目(漢字/かな表記など)最後にgrepかなんかで確認すること
！！というかどっちを採用するか後でゆっくり考えておくこと！！
○通り    ×とおり
○できる    ×出来る
○尚    ×なお
○ため    ×為
○行う    ×行なう    ×おこなう
○割り込み    ×割込み    ×割込
○読み込み    ×読込み    ×読込
○書き込み    ×書込み    ×書込
○受け付け    ×受付け    ×受付
○組み込む    ×組込む    ×組込
○待ち受け    ×待受け    ×待受
○取り扱い    ×取扱い    ×取扱
○繰り返し    ×繰返し
○振る舞い    ×振舞い    ×振舞
○ください    ×下さい
○度    ×たび
○済み    ×済
○異なる    ×ことなる
○事に    ×ことに
○～かもしれません    ×～かも知れません
○全ての    ×すべて
○既に    ×すでに
○カンマ区切    ×カンマ区切り
○負荷    ×付加    ※Load/Stress に関するもの
○その他    ×そのほか
○インタフェース    ×インターフェース

以下、localization用の対応一覧
-------------------FTP Request-------------------
Name    名前
Server Name or IP    サーバ名又はIP
Remote File    リモートファイル
Local File    ローカルファイル
Local File Contents    ローカルファイルコンテンツ
get(RETR) / put(STOR)    get(RETR) / put(STOR)
Use Binary mode ?    バイナリモードを使用
Save File in Response ?     サンプル結果にファイルを保存する
Username    ユーザ名
Password    パスワード
-------------------HTTP Request-------------------
Name    名前
Server    サーバ
Port    ポート
Protocol    プロトコル
Method    メソッド
Redirect Automatically    自動リダイレクト
Follow Redirects    リダイレクトをたどる
Use KeepAlive    KeepAliveを使用する
Use multipart/form-data for HTTP POST    multipart/form-dataをHTTP POSTに使用する
Path    パス
Send Parameters With the Request    リクエスト時に送信するパラメータ
File Path    ファイルパス
Parameter name    パラメータ名
MIME Type    MIME Type
Retrieve All Embedded Resources from HTML Files    HTMLファイルに組み込まれた全てのリソースを取得
Use as monitor    モニタとして使用する
Save response as MD5 hash?    応答をMD5ハッシュで保存する

-------------------Interleave Controller-------------------
name    名前
ignore sub-controller blocks    サブコントローラブロックを無視する
-------------------Random Controller-------------------
name    名前
-------------------Random Order Controller-------------------
name    名前
-------------------Throughput Controller-------------------
name    名前
Execution Style    実行スタイル
Throughput    スループット
Per User    ユーザ毎にカウントする
-------------------Runtime Controller-------------------
name    名前
Runtime (seconds)    実行時間(秒)
-------------------If Controller-------------------
name    名前
Condition    条件
Evaluate for all children    全ての子を判定する
-------------------While Controller-------------------
name    名前
Condition    条件
-------------------Switch Controller-------------------
name    名前
Switch Value    実行対象

-------------------18.2.12 ForEach Controller-------------------
Name    名前
Input variable prefix    入力変数のprefix
Output variable    出力変数
Use Separator    セパレータを使用する

-------------------18.2.13 Module Controller-------------------
Module to Run    実行させるモジュール

-------------------18.2.14 Include Controller-------------------
Filename    ファイル名
typodupeerror

人生unstable -- あるハッカー