Logic Controllers let you customize the logic that JMeter uses to
decide when to send requests. Logic Controllers may have as child elements any
of the following: Generative Controllers (requests), Configuration Elements, and other Logic
Controllers. Logic Controllers can change the order of requests coming from their
child elements. They can modify the requests themselves, cause JMeter to repeat
requests, etc.
ロジックコントローラーによって、
いつリクエストを送信するのかというロジックをカスタマイズすることができます。
ロジックコントローラーには以下の要素を子要素として追加することができます：
主コントローラー（リクエスト）、設定要素、その他のロジックコントローラー。
ロジックコントローラーは子要素の内容に合わせリクエストの順序を変更することができます。
リクエスト自体を変更したり、再度リクエストさせるなどもできます。
To understand the effect of Logic Controllers on a test plan, consider the
following test tree:
テストプラン上のロジックコントローラの効果を理解するために、
以下のようなテストツリーを考えてみましょう。
- Test Plan
- テストプラン
- Thread Group
- スレッドグループ
- Once Only Controller
- 一度だけ実行されるコントローラー
- Login Request (an )
- ログインリクエスト ()
- Load Search Page (HTTP Generative Controller)
- 検索ページのロード(HTTP主コントローラー)
- Interleave Controller
- インターリーブコントローラー
- Search "A" (HTTP Generative Controller)
- "A"を検索(HTTP主コントローラー)
- Search "B" (HTTP Generative Controller)
- "B"を検索(HTTP主コントローラー)
- HTTP default request (Configuration Element)
- HTTPリクエスト設定(各種設定)
- HTTP default request (Configuration Element)
- HTTPリクエスト設定(各種設定)
- Cookie Manager (Configuration Element)
- クッキーマネージャ(各種設定)
The first thing about this test is that the login request will be executed only
the first time through. Subsequent iterations will skip it. This is due to the
effects of the .
このテストにおいて、ログインリクエストは一度しか送られません。
その後の動作ではスキップされます。
これはの効果です。
After the login, the next Generative Controller loads the search page (imagine a
web application where the user logs in, and then goes to a search page to do a search). This
is just a simple request, not filtered through any Logic Controller.
ログイン後は、次の主コントローラーが検索ページをロードします
（Webアプリケーションにおいて、ユーザーがログイン後に検索ページへ行って検索するイメージです）。
これはシンプルなリクエストであり、どのロジックコントローラーのフィルターも通りません。
After loading the search page, we want to do a search. Actually, we want to do
two different searches. However, we want to re-load the search page itself between
each search. We could do this by having 4 simple HTTP request elements (load search,
search "A", load search, search "B"). Instead, we use the which passes on one child request each time through the test. It keeps the
ordering (ie - it doesn't pass one on at random, but "remembers" its place) of its
child elements. Interleaving 2 child requests may be overkill, but there could easily have
been 8, or 20 child requests.
検索ページをロード後、検索をします。ここで、二つの違う検索をしたいとしましょう。
しかし、二つの検索の間に検索ページをリロードしなければなりません。
これは4つの単純なHTTPリクエスト要素（検索ページのロード、"A"の検索、
検索ページのロード、"B"の検索）で行うこともできますが、
ここでは、ひとつの子リクエストをテスト中つねに通過するように
を使います。
インターリーブコントローラはその子要素の順番は保ちます
(例えば、ランダムなので通過しないこともあるがその場所は"覚えている")。
インターリーブされた二つの子要素のリクエストは重複削除されますが、
8または20程度の子リクエストは楽に保つことができます。
Note the that
belongs to the Interleave Controller. Imagine that "Search A" and "Search B" share
the same PATH info (an HTTP request specification includes domain, port, method, protocol,
path, and arguments, plus other optional items). This makes sense - both are search requests,
hitting the same back-end search engine (a servlet or cgi-script, let's say). Rather than
configure both HTTP Generative Controllers with the same information in their PATH field, we
can abstract that information out to a single Configuration Element. When the Interleave
Controller "passes on" requests from "Search A" or "Search B", it will fill in the blanks with
values from the HTTP default request Configuration Element. So, we leave the PATH field
blank for those requests, and put that information into the Configuration Element. In this
case, this is a minor benefit at best, but it demonstrates the feature.
は
インターリーブコントローラーの一種であることに注意してください。
検索Aと検索Bは同じパス(HTTPリクエストのドメイン、ポート、メソッド、
プロトコル等の詳細)をシェアすると思ってください。
つまり、両方のリクエストとも同じ検索エンジンのバックエンド
(サーブレットやCGIスクリプト等)にヒットするということです。
両方のHTTP主コントローラのPATHフィールドに同じことを書いておくより、
ひとつの設定要素に書いておくほうが簡素化できます。
そのため、これらリクエストのPATHフィールドは空白のままにしておき、
その情報は設定要素に書いておきます。
このケースでは大した恩恵を受けるものではありませんが、
特徴をデモするものとして使用しています。
The next element in the tree is another HTTP default request, this time added to the
Thread Group itself. The Thread Group has a built-in Logic Controller, and thus, it uses
this Configuration Element exactly as described above. It fills in the blanks of any
Request that passes through. It is extremely useful in web testing to leave the DOMAIN
field blank in all your HTTP Generative Controller elements, and instead, put that information
into an HTTP default request element, added to the Thread Group. By doing so, you can
test your application on a different server simply by changing one field in your Test Plan.
Otherwise, you'd have to edit each and every Generative Controller.
ツリー上の次の要素は別なHTTPリクエスト設定です。
この場合はスレッドグループ自身の設定要素として追加されています。
スレッドグループはビルトインのロジックコントローラを持っていて、
この設定要素は上のように厳密に定義されています。
通過するあらゆるリクエストのブランクを埋めます。
HTTP主コントローラ要素のドメインの設定はブランクにしておき、
そのかわり、スレッドグループに追加したHTTPリクエスト設定にその情報を欠いておきます
これによって、テストプラン上のひとつのフィールドを変更するだけで、
違うサーバー上のアプリケーションに対しテストプランを実行することができます。
The last element is a . A Cookie Manager should be added to all web tests - otherwise JMeter will
ignore cookies. By adding it at the Thread Group level, we ensure that all HTTP requests
will share the same cookies.
最後の要素はです。
クッキーマネージャは全てのテスト上で追加することができます。
設定されていなければJMeterはクッキーを無視します。
スレッドグループのレベルでクッキーマネージャを設定すると、
全てのHTTPリクエストで同じクッキーがシェアされます。
Logic Controllers can be combined to achieve various results. See the list of built-in
Logic Controllers.
ロジックコントローラーは様々な結果を導き出します。
built-in
Logic Controllersのリストを参照してください。
