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

bananan_wさんのトモダチの日記みんなの日記も見てね。 みんなの日記の更新状況はTwitterの@sradjp_journalsでもチェックできます。

10595847 journal
日記

bananan_wの日記: H264 Hardware accelerate encodingとわたし(3/3) 2

日記 by bananan_w

出来ました。

■環境
・OS:ArchLinux x64
・CPU:Intel(R) Core(TM) i7-4500U
・gstreamer-vaapi:0.5.8

■ポイント
Ubuntu 14.04 でもライブラリが古くて gstreamer-vaapi のコンパイルが通りません。
最新ソースから環境を整えたかったので、ArchLinuxを選択。

$ gst-launch-1.0 filesrc location=/tmp/test.mpg ! decodebin ! videoparse format=i420 width=720 height=480 framerate=30/1 ! vaapiencode_h264 ! qtmux ! filesink location=test.mp4

DVD画質のエンコードで約150FPS
MPEG2へのエンコードならもう少し早くて200FPSぐらい。

9269266 journal
日記

bananan_wの日記: H264 Hardware accelerate encodingとわたし(2/N) 2

日記 by bananan_w

エンコード環境整いました。CPUはSandyBridge。
vaapiのドライバにエンコード機能がついていないから、サンプルが動かなかった。

http://lists.freedesktop.org/archives/libva/2013-June/001766.html

昨日リリースされたドライバで、エンコード機能が実装されたので、
ubuntu-13.04に以下のパッケージをコンパイルして入れて、

libdrm-2.4.45
libva [git]
libva-intel-driver-1.2.0

$ ./h264encode

INPUT:Try to encode H264...
INPUT: RateControl : VBR
INPUT: Resolution : 176x144, 60 frames
INPUT: FrameRate : 30
INPUT: Bitrate : 182476
INPUT: Slieces : 1
INPUT: IntraPeriod : 30
INPUT: IDRPeriod : 60
INPUT: IpPeriod : 1
INPUT: Initial QP : 26
INPUT: Min QP : 0
INPUT: Source YUV : AUTO generated
INPUT: Coded Clip : /tmp/test.264
INPUT: Rec Clip : Not save reconstructed frame

libva info: VA-API version 0.34.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/local/lib/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_34
libva info: va_openDriver() returns 0
Use profile VAProfileH264High
Support rate control mode (0x12):CBR CQP
Support VAConfigAttribEncPackedHeaders
Support packed sequence headers
Support packed picture headers
Support packed misc headers
Support 1 RefPicList0 and 1 RefPicList1
Loading data into surface 15.....Complete surface loading
            \00000059(004504 bytes coded)

PERFORMANCE: Frame Rate : 304.57 fps (60 frames, 197 ms (3.28 ms per frame))
PERFORMANCE: Compression ratio : 8:1
PERFORMANCE: UploadPicture : 148 ms (2.47, 75.13% percent)
PERFORMANCE: vaBeginPicture : 0 ms (0.00, 0.00% percent)
PERFORMANCE: vaRenderHeader : 1 ms (0.02, 0.51% percent)
PERFORMANCE: vaEndPicture : 18 ms (0.30, 9.14% percent)
PERFORMANCE: vaSyncSurface : 18 ms (0.30, 9.14% percent)
PERFORMANCE: SavePicture : 5 ms (0.08, 2.54% percent)
PERFORMANCE: Others : 7 ms (0.12, 3.55% percent)
(Multithread enabled, the timing is only for reference)

動きました。
ようやくスタートラインに立てました。

9218926 journal
日記

bananan_wの日記: H264 Hardware accelerate encodingとわたし(1/N) 5

日記 by bananan_w

http://www.phoronix.com/scan.php?page=news_item&px=MTM3MTU

どうやらLinuxでもIntel HD graphic のロジックを使うと出来るらしいのですが、
ffmpegにもlibx264にも実装されてないような感じです。

これは実装して楽しんでみるチャンス。
と、とらえて環境構築から色々とあがいてみる。

https://01.org/linuxgraphics/downloads/2013/2013q1-intel-graphics-stack-release

このあたりのモジュールを更新すると、
サンプルが動かせそうな気がするので、挑戦している。

http://cgit.freedesktop.org/libva/tree/test/encode/h264encode.c

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 * 3 = 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コントローラは関連する1セットの変数を通じてループします。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秒)
typodupeerror

目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond

読み込み中...