レイテンシーは、ログインにかかる時間に設定されます。

このサンプラーを使用すると、HTTP/HTTPS 要求を Web サーバーに送信できます。また、JMeter が画像やその他の埋め込みリソースの HTML ファイルを解析し、それらを取得するために HTTP 要求を送信するかどうかを制御することもできます。次の種類の埋め込みリソースが取得されます。

• 画像
• アプレット
• スタイルシート (CSS) およびそれらのファイルから参照されるリソース
• 外部スクリプト
• フレーム、iframe
• 背景画像（本体、表、TD、TR）
• 背景音

デフォルトのパーサーはorg.apache.jmeter.protocol.http.parser.LagartoBasedHtmlParser です。これは、プロパティ「 htmlparser.className」を使用して変更できます。詳細については、 jmeter.propertiesを参照してください。

複数の要求を同じ Web サーバーに送信する場合は、HTTP 要求の既定の 構成要素を使用することを検討してください。これにより、HTTP 要求ごとに同じ情報を入力する必要がなくなります。

または、HTTP リクエストを手動で追加する代わりに、JMeter のHTTP(S) テスト スクリプト レコーダーを使用して作成することもできます。これにより、多数の HTTP リクエストまたは多数のパラメーターを含むリクエストがある場合に、時間を節約できます。

サンプラーを定義するために使用される 3 つの異なるテスト要素があります。

AJP/1.3 サンプラー

Tomcat mod_jk プロトコルを使用します (Apache httpd を必要とせずに AJP モードで Tomcat をテストできます)。AJP Sampler は複数ファイルのアップロードをサポートしていません。最初のファイルのみが使用されます。

HTTP リクエスト

これには、使用する HTTP プロトコルの実装を選択する実装ドロップダウン ボックスがあります。

ジャワ

JVM が提供する HTTP 実装を使用します。これには、HttpClient 実装と比較していくつかの制限があります。以下を参照してください。

HTTPClient4

Apache HttpComponents HttpClient 4.x を使用します。

ブランク値

HTTP サンプラーの実装を設定しないため、存在する場合は HTTP 要求のデフォルトに依存するか、jmeter.propertiesで定義されたjmeter.httpsamplerプロパティに依存します

GraphQL HTTP リクエスト

これはHTTP リクエストの GUI バリエーションであり、GraphQL Query、Variables、およびOperation Nameを表示または編集するためのより便利な UI 要素を提供し、同じサンプラーを使用して内部でそれらを HTTP Arguments に自動的に変換します。以下の UI 要素は、HTTP/HTTPS リクエストを介した GraphQL にとってあまり便利ではないか、無関係であるため、非表示にするかカスタマイズします。

• メソッド: GraphQL over HTTP 仕様に準拠した POST メソッドと GET メソッドのみが使用可能です。デフォルトでは POST メソッドが選択されています。
• [パラメーター] タブと[投稿本文] タブ: 代わりに、クエリ、変数、および操作名の UI 要素を使用して、パラメーターの内容を表示または編集できます。
• [ファイルのアップロード] タブ: GraphQL クエリとは関係ありません。
• [Advanced] タブの [ Embedded Resources from HTML Files ] セクション: GraphQL JSON 応答には関係ありません。

Java HTTP 実装にはいくつかの制限があります。

• 接続の再利用方法を制御することはできません。接続が JMeter によって解放されると、同じスレッドによって再利用される場合とされない場合があります。
• API はシングル スレッドでの使用に最適です。さまざまな設定がシステム プロパティによって定義されるため、すべての接続に適用されます。
• Kerberos 認証のサポートなし
• Keystore Config を使用したクライアント ベースの証明書のテストはサポートされていません。
• 再試行メカニズムの制御の向上
• 仮想ホストはサポートしていません。
• 次のメソッドのみをサポートします: GET、POST、HEAD、OPTIONS、PUT、DELETEおよびTRACE
• DNS Cache Managerによる DNS キャッシングの制御の向上

要求がサーバーまたはプロキシのログイン認証を必要とする場合 (つまり、ブラウザーがポップアップ ダイアログ ボックスを作成する場合)、HTTP Authorization Manager構成要素も追加する必要があります。通常のログイン (つまり、ユーザーがフォームにログイン情報を入力する場所) の場合、フォーム送信ボタンが何をするかを理解し、適切なメソッド (通常はPOST ) とフォーム定義から適切なパラメーターを使用して HTTP リクエストを作成する必要があります。 . ページが HTTP を使用している場合は、JMeter プロキシを使用してログイン シーケンスを取得できます。

スレッドごとに個別の SSL コンテキストが使用されます。単一の SSL コンテキスト (ブラウザの標準的な動作ではない) を使用する場合は、JMeter プロパティを設定します。

https.sessioncontext.shared=true

httpclient.reset_state_on_thread_group_iteration=true

https.default.protocol=SSLv3

JMeter では、プロパティhttps.socket.protocolsを変更することで、追加のプロトコルを有効にすることもできます。

リクエストで Cookie を使用する場合は、 HTTP Cookie Managerも必要になります 。これらの要素のいずれかをスレッド グループまたは HTTP 要求に追加できます。認証または Cookie が必要な HTTP リクエストが複数ある場合は、要素をスレッド グループに追加します。これにより、すべての HTTP 要求コントローラーが同じ承認マネージャーと Cookie マネージャーの要素を共有します。

リクエストが「URL 書き換え」と呼ばれる手法を使用してセッションを維持する場合は、 追加の構成手順についてセクション6.1 URL 書き換えによるユーザー セッションの処理を参照してください。

このサンプラーを使用すると、JDBC リクエスト (SQL クエリ) をデータベースに送信できます。

これを使用する前に、 JDBC 接続構成構成要素 をセットアップする必要があり ます

変数名リストが指定されている場合、Select ステートメントによって返される行ごとに、対応する列の値を使用して変数が設定され (変数名が指定されている場合)、行数も設定されます。たとえば、Select ステートメントが 2 行 3 列を返し、変数リストがA,,Cの場合、次の変数が設定されます。

A_#=2 (行数)
A_1=列 1、行 1
A_2=列 1、行 2
C_#=2 (行数)
C_1=列 3、行 1
C_2=列 3、行 2

Select ステートメントがゼロ行を返す場合、A_#およびC_#変数は0に設定され、他の変数は設定されません。

古い変数は必要に応じてクリアされます。たとえば、最初の選択で 6 行が取得され、2 番目の選択で 3 行しか返されない場合、4、5、6 行の追加の変数が削除されます。

このサンプラーを使用すると、 org.apache.jmeter.protocol.java.sampler.JavaSamplerClientインターフェイスを実装する Java クラスを制御できます 。このインターフェースの独自の実装を作成することにより、JMeter を使用して、複数のスレッド、入力パラメーター制御、およびデータ収集を利用できます。

プルダウン メニューには、クラスパスで JMeter によって検出されたすべての実装のリストが表示されます。パラメータは、実装で定義されているように、以下の表で指定できます。2 つの簡単な例 ( JavaTestとSleepTest ) が提供されています。

JavaTestサンプル サンプラーは、ほぼすべてのフィールドに値を設定できるため、テスト計画を確認するのに役立ちます 。これらはアサーションなどで使用できます。フィールドでは変数を使用できるため、これらの値を簡単に確認できます。

複数の要求を同じ LDAP サーバーに送信する場合は 、各 LDAP 要求に同じ情報を入力する必要がないように、 LDAP 要求の既定の構成要素を使用することを検討してください。

複数の要求を同じ LDAP サーバーに送信する場合は、 LDAP 要求ごとに同じ情報を入力する必要がないように、 LDAP 拡張要求デフォルト構成要素の使用を検討してください。

AccessLogSampler は、アクセス ログを読み取り、http 要求を生成するように設計されています。アクセス ログに慣れていない方のために説明すると、アクセス ログとは、ウェブサーバーが受け付けたすべてのリクエストを保持するログです。これは、すべての画像、CSS ファイル、JavaScript ファイル、html ファイルなどを意味します。

Tomcat は、アクセス ログに共通の形式を使用します。これは、共通ログ形式を使用するすべての Web サーバーが AccessLogSampler を使用できることを意味します。一般的なログ形式を使用するサーバーには、Tomcat、Resin、Weblogic、および SunOne が含まれます。一般的なログ形式は次のようになります。

127.0.0.1 - - [21/Oct/2003:05:37:21 -0500] "GET /index.jsp?%2Findex.jsp= HTTP/1.1" 200 8343

将来的には、応答コード200を持たないエントリを除外するとよいでしょう。サンプラーの拡張はかなり簡単です。実装する必要がある 2 つのインターフェイスがあります。

• org.apache.jmeter.protocol.http.util.accesslog.LogParser
• org.apache.jmeter.protocol.http.util.accesslog.Generator

AccessLogSampler の現在の実装では、ジェネレーターを使用して新しい HTTPSampler を作成します。サーバー名、ポート、および取得イメージは、AccessLogSampler によって設定されます。次に、整数1を指定してパーサーが呼び出され、 1 つのエントリを解析するように指示されます。その後、 HTTPSampler.sample()を呼び出してリクエストを行います。

サンプル = (HTTPSampler) GENERATOR.generateRequest();
samp.setDomain(this.getDomain());
samp.setPort(this.getPort());
samp.setImageParser(this.isImageParser());
PARSER.parse(1);
res = samp.sample();
res.setSampleLabel(samp.toString());

• setGenerator(ジェネレータ)
• パース(整数)

Generatorインターフェイスを 実装するクラスは、すべてのメソッドの具体的な実装を提供する必要があります。いずれかのインターフェースを実装する方法の例については、 StandardGeneratorおよびTCLogParserを参照してください。

このサンプラーを使用すると、BeanShell スクリプト言語を使用してサンプラーを作成できます。

BeanShell の使用の詳細については、BeanShell の Web サイトを参照してください。

テスト要素は、ThreadListenerおよびTestListenerインターフェイス メソッドをサポートします。これらは初期化ファイルで定義する必要があります。定義の例 については、ファイルBeanShellListeners.bshrcを参照してください。

BeanShell サンプラーは、Interruptibleインターフェースもサポートしています。interrupt()メソッドは、スクリプトまたは init ファイルで定義できます。

JSR223 Sampler を使用すると、JSR223 スクリプト コードを使用して、変数の作成/更新に必要なサンプルまたは計算を実行できます。

SampleResult.setIgnore();

JSR223 テスト要素には、パフォーマンスを大幅に向上させる機能 (コンパイル) があります。この機能を活用するには:

• インライン化する代わりに、スクリプト ファイルを使用します。この機能が ScriptEngine で利用可能な場合、JMeter はそれらをコンパイルし、キャッシュします。
• または、スクリプト テキストを使用し、[利用可能な場合はコンパイル済みスクリプトをキャッシュする]プロパティをオンにします。
  この機能を使用する場合は、スクリプト コードで JMeter 変数または JMeter 関数呼び出しをスクリプト コードで直接使用しないようにしてください。キャッシュは最初の置換のみをキャッシュするためです。代わりにスクリプト パラメータを使用します。
  キャッシングとコンパイルの恩恵を受けるには、スクリプトに使用される言語エンジンが JSR223 Compilableインターフェースを実装する必要があります (Groovy はこれらの 1 つですが、java、beanshell、javascript はそうではありません)。
  Groovy をスクリプト言語として使用し、利用可能な場合はコンパイル済みスクリプトをキャッシュするをチェックしない場合(キャッシュが推奨されます)、 バージョン 2.4.6 での Groovy メモリ リークのため、 この JVM プロパティ-Dgroovy.use.classvalue=trueを設定する必要があります。以下を参照してください。

  • GROOVY-7683
  • GROOVY-7591
  • JDK-8136353

jsr223.compiled_scripts_cache_size=100

TCP サンプラーは、指定されたサーバーへの TCP/IP 接続を開きます。次に、テキストを送信し、応答を待ちます。

[接続の再利用] が選択されている場合、まったく同じホスト名文字列とポートが使用されている場合、接続は同じスレッド内のサンプラー間で共有されます。異なるホスト/ポートの組み合わせは、異なるスレッドと同様に、異なる接続を使用します。「接続の再利用」と「接続のクローズ」の両方が選択されている場合、サンプラーの実行後にソケットがクローズされます。次のサンプラーでは、別のソケットが作成されます。各スレッド ループの最後でソケットを閉じたい場合があります。

エラーが検出された場合、または「接続の再利用」が選択されていない場合、ソケットは閉じられます。次のサンプルで別のソケットが再度開かれます。

次のプロパティを使用して、その操作を制御できます。

tcp.status.prefix

ステータス番号の前のテキスト

tcp.status.suffix

ステータス番号に続くテキスト

tcp.status.properties

ステータス コードをメッセージに変換するプロパティ ファイルの名前

tcp.handler

TCP ハンドラー クラスの名前 (デフォルトTCPClientImpl ) - GUI で指定されていない場合にのみ使用されます。

ユーザーは独自の実装を提供できます。クラスはorg.apache.jmeter.protocol.tcp.sampler.TCPClientを拡張する必要があります。

現在、以下の実装が提供されています。

• TCPClientImpl
• BinaryTCPClientImpl
• LengthPrefixedBinaryTCPClientImpl

TCPClientImpl

この実装はかなり基本的なものです。応答を読み取るとき、これがプロパティtcp.eolByteの設定によって定義されている場合は行バイトの終わりまで、それ以外の場合は入力ストリームの終わりまで読み取ります。tcp.charsetを設定することにより、文字セットのエンコーディングを制御できます。これは、デフォルトでプラットフォームのデフォルトのエンコーディングになります。

BinaryTCPClientImpl

この実装は、16 進数でエンコードされた文字列でなければならない GUI 入力をバイナリに変換し、応答を読み取るときにその逆を実行します。応答を読み取るとき、これがプロパティtcp.BinaryTCPClient.eomByteを設定して定義されている場合は、メッセージ バイトの最後まで読み取ります。それ以外の場合は、入力ストリームの最後まで読み取ります。

LengthPrefixedBinaryTCPClientImpl

この実装は、バイナリ メッセージ データにバイナリ長バイトをプレフィックスとして付けることにより、BinaryTCPClientImpl を拡張します。長さプレフィックスのデフォルトは 2 バイトです。これは、プロパティtcp.binarylength.prefix.lengthを設定することで変更できます。

タイムアウト処理

タイムアウトが設定されている場合、タイムアウトになると読み取りが終了します。したがって、eolByte / eomByteを使用している場合は、タイムアウトが十分に長いことを確認してください。そうしないと、読み取りが早期に終了します。

応答処理

tcp.status.prefixが定義されている 場合は、応答メッセージで、それに続くサフィックスまでのテキストが検索されます。そのようなテキストが見つかった場合は、それを使用して応答コードを設定します。次に、応答メッセージがプロパティー・ファイル (提供されている場合) からフェッチされます。

プレとサフィックスの使用¶

たとえば、接頭辞 = " [ " および接尾辞 = " ] " の場合、次の応答:

[J28] XI123,23,GBP,CR

応答コードはJ28になります。

" 400 "-" 499 " および " 500 "-" 599 " の範囲の応答コードは、現在、失敗と見なされます。他のすべては成功しています。[これは設定可能にする必要があります!]

JMS パブリッシャーは、指定された宛先 (トピック/キュー) にメッセージをパブリッシュします。JMS に慣れていない方のために説明すると、JMS はメッセージング用の J2EE 仕様です。市場には多数の JMS サーバーがあり、いくつかのオープン ソース オプションがあります。

JMS サブスクライバーは、指定された宛先 (トピックまたはキュー) のメッセージにサブスクライブします。JMS に慣れていない方のために説明すると、JMS はメッセージング用の J2EE 仕様です。市場には多数の JMS サーバーがあり、いくつかのオープン ソース オプションがあります。

このサンプラーは、ポイントツーポイント接続 (キュー) を介して JMS メッセージを送信し、オプションで受信します。pub/sub メッセージとは異なり、通常はトランザクションの処理に使用されます。

request_onlyは通常、JMS システムに負荷をかけるために使用されます。
request_replyは、リクエスト キューに送信されたメッセージを処理する JMS サービスの応答時間をテストする場合に使用します。このモードは、このサービスによって送信された応答キューで応答を待機するためです。
Browseは、現在のキューの深さ、つまりキューにあるメッセージの数を返します。
readは、キューからメッセージを読み取ります (存在する場合)。
clearは、キューをクリアします。つまり、キューからすべてのメッセージを削除します。

JMeter は、プロパティjava.naming.security.[principal|credentials] (存在する場合) を使用して、キュー接続を作成します。この動作が望ましくない場合は、JMeter プロパティ JMSSampler.useSecurity.properties=falseを設定します。

• JMeter のテスト インターフェイスを使用するのではなく、JUnit のTestCaseクラスを拡張するクラスの jar ファイルをスキャンします。これには、任意のクラスまたはサブクラスが含まれます。
• JUnit テスト jar ファイルは、 /libディレクトリではなくjmeter/lib/junitに配置する必要があります。「 user.classpath 」プロパティを使用して、 TestCaseクラスを探す場所を指定することもできます。
• JUnit サンプラーは、 Java Requestのような構成に名前と値のペアを使用しません。サンプラーは、 setUpとtearDownがテストを正しく構成すると想定しています。
• サンプラーはテスト メソッドの経過時間のみを測定し、setUpとtearDownは含まれません。
• テスト メソッドが呼び出されるたびに、JMeter は結果をリスナーに渡します。
• oneTimeSetUpとoneTimeTearDownのサポートはメソッドとして行われます。JMeter はマルチスレッドであるため、Maven と同じ方法でoneTimeSetUp / oneTimeTearDownを呼び出すことはできません。
• サンプラーは、予期しない例外をエラーとして報告します。標準の JUnit テスト ランナーと JMeter の実装の間には、いくつかの重要な違いがあります。テストごとにクラスの新しいインスタンスを作成するのではなく、JMeter はサンプラーごとに 1 つのインスタンスを作成し、それを再利用します。これは、チェックボックス「サンプルごとに新しいインスタンスを作成する」で変更できます。

パブリック クラス myTestCase {
  public myTestCase() {}
}

パブリック クラス myTestCase {
  public myTestCase(文字列テキスト) {
    スーパー（テキスト）;
  }
}

Mail Reader Sampler は、POP3(S) または IMAP(S) プロトコルを使用してメール メッセージを読み取る (およびオプションで削除する) ことができます。

このサンプラーは、サンプルを生成しなくても一時停止を含めることができるため、Transaction Controller と組み合わせて使用​​ することもできます。可変遅延の場合、一時停止時間をゼロに設定し、Timer を子として追加します。

「停止」アクションは、進行中のサンプルが完了した後で、スレッドまたはテストを停止します。「Stop Now」アクションは、サンプルが完了するのを待たずにテストを停止します。アクティブなサンプルが中断されます。一部のスレッドが 5 秒の制限時間内に停止しなかった場合、GUI モードでメッセージが表示されます。Stopコマンドを使用して、スレッドが停止するかどうかを確認できますが、そうでない場合は、JMeter を終了する必要があります。CLI モードでは、一部のスレッドが 5 秒の制限時間内に停止しなかった場合、JMeter は終了します。

SMTP Sampler は、SMTP/SMTPS プロトコルを使用してメール メッセージを送信できます。接続のセキュリティ プロトコル (SSL および TLS) とユーザー認証を設定できます。セキュリティ プロトコルが使用されている場合、サーバー証明書の検証が行われます。
この検証を処理するには、次の 2 つの方法があります。

すべての証明書を信頼する

これは、証明書チェーンの検証を無視します

ローカルのトラストストアを使用する

このオプションを使用すると、証明書チェーンはローカルのトラストストア ファイルに対して検証されます。

OS Process Sampler は、ローカル マシンでコマンドを実行するために使用できるサンプラーです。
コマンドラインから実行できるすべてのコマンドを実行できるようにする必要があります。
リターン コードの検証を有効にし、予想されるリターン コードを指定できます。

OS シェルは通常、コマンドライン解析を提供することに注意してください。これは OS によって異なりますが、通常、シェルは空白でパラメーターを分割します。一部のシェルは、ワイルドカード ファイル名を展開します。しない人もいます。引用メカニズムも OS によって異なります。サンプラーは、意図的に解析や引用処理を行いません。コマンドとそのパラメーターは、実行可能ファイルが期待する形式で提供する必要があります。これは、サンプラー設定が OS 間で移植できないことを意味します。

多くの OS には、個別の実行可能ファイルとして提供されていない組み込みコマンドがいくつかあります。たとえば、Windows DIRコマンドはコマンド インタープリター ( CMD.EXE ) の一部です。これらのビルトインは、独立したプログラムとして実行することはできませんが、適切なコマンド インタープリターへの引数として提供する必要があります。

たとえば、Windows コマンドライン: DIR C:\TEMPは次のように指定する必要があります。

指示：

CMD

パラメータ 1:

/C

パラメータ 2:

DIR

パラメータ 3:

C:\TEMP

このサンプラーを使用すると、リクエストを MongoDB に送信できます。

これを使用する前に、 MongoDB Source Config構成要素 をセットアップする必要があります

このサンプラーを使用すると、Bolt プロトコルを介して Cypher クエリを実行できます。

これを使用する前に、ボルト接続構成を設定する必要があります

すべての要求は、プールから取得した接続を使用し、サンプラーが完了するとプールに返します。接続プールのサイズはドライバーのデフォルト (~100) を使用し、現時点では構成できません。

測定された応答時間は、暗号クエリを実行する時間と、データベースから返された結果を消費する時間の両方を含む、「完全な」クエリ実行に対応します。

Simple Logic Controller を使用すると、サンプラーやその他のロジック コントローラーを整理できます。他のロジック コントローラとは異なり、このコントローラにはストレージ デバイス以上の機能はありません。

ジェネレーティブ コントローラーまたはロジック コントローラーをループ コントローラーに追加すると、JMeter は、スレッド グループに指定したループ値に加えて、それらを特定の回数ループします。たとえば、ループ カウントが 2 のループ コントローラに 1 つの HTTP リクエストを追加し、スレッド グループのループ カウントを 3 に設定すると、JMeter は合計2 * 3 = 6のHTTP リクエストを送信します。

1 回限りのロジック コントローラーは、JMeter に対して、その内部のコントローラーをスレッドごとに 1 回だけ処理し、テスト計画のさらなる反復中にその下にあるすべての要求を渡すように指示します。

一度だけのコントローラーは、ループしている親コントローラーの最初の反復中に常に実行されるようになりました。したがって、5 回ループするように指定されたループ コントローラーの下に 1 回限りのコントローラーが配置されている場合、1 回限りのコントローラーはループ コントローラーを介した最初の反復でのみ (つまり、5 回ごとに) 実行されます。

これは、1 回限りのコントローラーがスレッド グループ (スレッドごとのテストごとに 1 回だけ実行される) の下に配置された場合でも以前に期待されたとおりに動作することを意味しますが、ユーザーは 1 回限りのコントローラーをより柔軟に使用できるようになりました。

ログインが必要なテストでは、セッションを確立するために各スレッドがログインする必要があるのは 1 回だけであるため、このコントローラーにログイン要求を配置することを検討してください。

ジェネレーティブ コントローラーまたはロジック コントローラーをインターリーブ コントローラーに追加すると、JMeter はループの反復ごとに他の各コントローラーを交互に使用します。

Random Logic Controller は Interleave Controller と同様に動作しますが、サブコントローラーとサンプラーを順番に処理する代わりに、各パスでランダムに 1 つを選択する点が異なります。

Random Order Controller は、各子要素を最大 1 回実行するという点で Simple Controller によく似ていますが、ノードの実行順序はランダムです。

スループット コントローラを使用すると、実行頻度を制御できます。次の 2 つのモードがあります。

• 実行率
• 総実行数

実行率

コントローラーは、テスト計画を通じて特定の割合の反復を実行します。

総実行数

特定の回数の実行が発生した後、コントローラーの実行を停止します。

ランタイム コントローラーは、その子の実行時間の長さを制御します。コントローラーは、構成されたランタイムを超える まで子を実行します。

If コントローラーを使用すると、ユーザーはその下のテスト要素 (その子) を実行するかどうかを制御できます。

デフォルトでは、条件は最初のエントリで 1 回だけ評価されますが、コントローラーに含まれる実行可能な要素ごとに評価するオプションがあります。

最良のオプション (デフォルト) は、[条件を変数式として解釈しますか? ] をオンにすることです。の場合、条件フィールドには 2 つのオプションがあります。

• オプション 1: trueまたはfalseを含む変数を使用する
  最後のサンプルが成功したかどうかをテストする場合は、${JMeterThread.last_sample_ok}を使用できます。

  
• オプション 2: 関数 ( ${__jexl3()}をお勧めします) を使用して、 trueまたはfalseを返さなければならない式を評価します

  

"${myVar}" == "\${myVar}"

"${myVar}" != "\${myVar}"

While コントローラーは、条件が " false " になるまで子を実行します。

可能な条件値:

• 空白 - ループの最後のサンプルが失敗したときにループを終了します
• LAST - ループの最後のサンプルが失敗したときにループを終了します。ループの直前の最後のサンプルが失敗した場合は、ループに入らないでください。
• それ以外の場合 - 条件が文字列 " false "と等しい場合、ループを終了します (またはループに入らないでください) 。

• ${VAR} - VARが他のテスト要素によって false に設定されている場合
• ${__jexl3(${C}==10)}
• ${__jexl3("${VAR2}"=="abcd")}
• ${_P(property)} - プロパティが別の場所で「false」に設定されている場合

スイッチ コントローラーは、反復ごとに従属要素の 1 つを実行するという点でインターリーブ コントローラーのように機能 しますが、それらを順番に実行するのではなく、コントローラーはスイッチ値によって定義された要素を実行します。

スイッチ値が範囲外の場合、ゼロ番目の要素が実行されるため、数値の場合のデフォルトとして機能します。値が空の文字列の場合は、0 番目の要素も実行されます。

値が非数値 (および空でない) の場合、スイッチ コントローラーは同じ名前の要素を探します (大文字と小文字は区別されます)。一致する名前がない場合は、「default」(大文字と小文字は区別されません) という名前の要素が選択されます。デフォルトがない場合、要素は選択されず、コントローラーは何も実行しません。

ForEach コントローラーは、一連の関連する変数の値をループ処理します。サンプラー (またはコントローラー) を ForEach コントローラーに追加すると、すべてのサンプル (またはコントローラー) が 1 回以上実行され、ループごとに変数に新しい値が設定されます。入力は、アンダースコアと数字で拡張されたいくつかの変数で構成する必要があります。そのような各変数には値が必要です。たとえば、入力変数の名前がinputVarの場合、次の変数が定義されている必要があります。

• inputVar_1 = ウェンディ
• inputVar_2 = チャールズ
• inputVar_3 = ピーター
• inputVar_4 = ジョン

注: " _ " セパレーターはオプションになりました。

戻り変数が「returnVar」として指定されると、ForEach コントローラーの下のサンプラーとコントローラーのコレクションが4回連続して実行され、戻り変数がそれぞれ上記の値を持ち、サンプラーで使用できるようになります。

これは、正規表現ポストプロセッサで実行するのに特に適しています。これにより、前のリクエストの結果データから必要な入力変数を「作成」できます。「 _ 」セパレーターを省略することにより、ForEach コントローラーを使用して、入力変数refName_gを使用してグループをループ処理できます。また、フォームrefName_${Cの入力変数を使用して、すべての一致のすべてのグループをループ処理できます。}_g、ここでCはカウンター変数です。

Module Controller は、実行時にテスト計画のフラグメントを現在のテスト計画に置き換えるメカニズムを提供します。

テスト計画フラグメントは、コントローラーとそれに含まれるすべてのテスト要素 (サンプラーなど) で構成されます。フラグメントは、任意のスレッド グループに配置できます。フラグメントがスレッド グループにある場合、そのコントローラーを無効にして、フラグメントがモジュール コントローラー以外によって実行されないようにすることができます。または、フラグメントをダミーのスレッド グループに格納し、スレッド グループ全体を無効にすることもできます。

複数のフラグメントが存在する可能性があり、それぞれの下に異なる一連のサンプラーがあります。モジュール コントローラーを使用すると、ドロップダウン ボックスで適切なコントローラーを選択するだけで、これらの複数のテスト ケースを簡単に切り替えることができます。これにより、多くの代替テスト計画を迅速かつ簡単に実行できるようになります。

フラグメント名は、コントローラー名とそのすべての親名で構成されます。例えば：

テスト計画 / プロトコル: JDBC / コントロール / インターリーブ コントローラー (Module1)

モジュールコントローラーで使用されるフラグメントには一意の名前が必要です。これは、名前がテスト計画の再読み込み時にターゲット コントローラーを見つけるために使用されるためです。このため、上記の例に示すように、コントローラー名をデフォルトから変更することをお勧めします。そうしないと、新しい要素がテスト計画に追加されたときに誤って重複が作成される可能性があります。

インクルード コントローラーは、外部 JMX ファイルを使用するように設計されています。これを使用するには、テスト計画の下にテスト フラグメントを作成し、その下に必要なサンプラー、コントローラーなどを追加します。次に、テスト計画を保存します。ファイルは、他のテスト計画の一部として含める準備ができました。

便宜上、デバッグ目的でスレッド グループを外部 JMX ファイルに追加することもできます。モジュール コントローラーを使用して、テスト フラグメントを参照できます。インクルード プロセス中、スレッド グループは無視されます。

テストで Cookie マネージャーまたはユーザー定義変数を使用する場合、これらはインクルード ファイルではなく、最上位のテスト計画に配置する必要があります。そうしないと、動作が保証されません。

prefix + Filenameで 指定された場所にファイルが見つからない場合、コントローラは JMX 起動ディレクトリに関連する Filenameを開こうとします。

トランザクション コントローラーは、ネストされたテスト要素の実行にかかった全体の時間を測定する追加のサンプルを生成します。

次の 2 つの操作モードがあります。

• 追加のサンプルは、ネストされたサンプルの後に追加されます
• 追加のサンプルは、ネストされたサンプルの親として追加されます

生成されたサンプル時間には、ネストされたサンプラーのすべての時間が含まれます。デフォルト (2.11 以降) のタイマーとプリ/ポスト プロセッサの処理時間は除きます。クロックの分解能によっては、個々のサンプラーとタイマーの合計よりもわずかに長くなる場合があります。コントローラーが開始時刻を記録した後、最初のサンプルが開始する前に、クロックがカチカチ音をたてる場合があります。最後も同様。

生成されたサンプルは、そのすべてのサブサンプルが成功した場合にのみ成功したと見なされます。

親モードでは、個々のサンプルは引き続きツリー ビュー リスナーに表示されますが、他のリスナーに個別のエントリとして表示されることはなくなりました。また、サブサンプルは CSV ログ ファイルには表示されませんが、XML ファイルに保存できます。

Recording Controller は、プロキシ サーバーがサンプルを記録する場所を示すプレース ホルダーです。試運転中はシンプルコントローラーと同様、効果はありません。ただし、HTTP(S) Test Script Recorderを使用した記録中、記録されたすべてのサンプルはデフォルトで Recording Controller に保存されます。

クリティカル セクション コントローラーは、コントローラーの子を実行する前に名前付きロックが取得されるため、その子要素 ​​(サンプラー/コントローラーなど) が 1 つのスレッドによってのみ実行されるようにします。

以下に示すように、構成ポップアップを使用して、さまざまな項目を結果ログ ファイル (JTL) に保存するようにリスナーを構成できます。デフォルトは、 Listener Default Configurationドキュメントで説明されているように定義されています。名前の後に ( CSV )が付いている項目は、CSV 形式にのみ適用されます。( XML )が付いている項目は、XML 形式にのみ適用されます。現在、CSV 形式を使用して改行を含むアイテムを保存することはできません。

Cookie、メソッド、およびクエリ文字列は、「Sampler Data」オプションの一部として保存されることに注意してください。

Graph Results リスナーは、すべてのサンプル時間をプロットする単純なグラフを生成します。グラフの下部に沿って、現在のサンプル (黒)、すべてのサンプルの現在の平均 (青)、現在の標準偏差 (赤)、および現在のスループット レート (緑) がミリ秒単位で表示されます。

スループットの数値は、サーバーが処理した 1 分あたりの実際の要求数を表します。この計算には、テストに追加したすべての遅延と JMeter 独自の内部処理時間が含まれます。このような計算を行う利点は、この数値が実際のものを表していることです。実際、サーバーは 1 分間にそれだけ多くのリクエストを処理しており、スレッドの数を増やしたり、遅延を減らしたりして、サーバーの最大スループットを検出できます。一方、遅延と JMeter の処理を​​考慮して計算した場合、その数値から何を結論できるかは不明です。

アサーション結果ビジュアライザーには、取得した各サンプルのラベルが表示されます。また、テスト計画の一部であるアサーションの失敗も報告します。

応答を表示するにはいくつかの方法があり、左側のパネルの下部にあるドロップダウン ボックスで選択できます。

マッチ数: 74
Match[1]=#関数
Match[2]=#what_can_do
Match[3]=#where
Match[4]=#方法
Match[5]=#function_helper
Match[6]=#関数
Match[7]=#__regexFunction
Match[8]=#__regexFunction_parms
Match[9]=#__カウンター
… 等々 …

マッチ数: 26
Match[1][0]=JMeter - Apache JMeter</title>
Match[1][1]=JMeter
Match[2][0]=JMeter" title="JMeter" border="0"/></a>
Match[2][1]=JMeter
Match[3][0]=JMeterCommitters">貢献者</a>
Match[3][1]=JMeterCommitters
… 等々 …

画像/
オーディオ/
ビデオ/

自動スクロール？オプションは、ツリー選択で最後のノードを表示することを許可します

検索オプションを使用すると、ほとんどのビューで表示されたデータを検索することもできます 。検索の結果は、上のディスプレイで強調表示されます。たとえば、下のコントロール パネルのスクリーンショットは、「Java」を検索した結果の 1 つを示しています。検索は表示されているテキストに対して行われるため、テキスト ビューと HTML ビューを検索すると異なる結果が得られる場合があることに注意してください。
注: 正規表現は Java エンジンを使用します (Regular Expression Extractor または Regexp Tester ビューのような ORO エンジンではありません)。

content-typeが指定されていない 場合、そのコンテンツはどの応答データ パネルにも表示されません。この場合、[応答をファイルに保存] を使用してデータを保存できます。応答データは引き続きサンプル結果で使用できるため、ポストプロセッサを使用してアクセスできることに注意してください。

応答データが 200K より大きい場合、表示されません。この制限を変更するには、JMeter プロパティview.results.tree.max_sizeを設定します。Save Responses to a file を使用して、応答全体をファイルに保存することもでき ます。

追加のレンダラーを作成できます。クラスはインターフェースorg.apache.jmeter.visualizers.ResultRendererを実装する か、抽象クラスorg.apache.jmeter.visualizers.SamplerResultTabを拡張する必要があり、コンパイルされたコードは JMeter で使用できる必要があります (たとえば、lib/ extディレクトリ)。

スループットは、サンプラ ターゲット (たとえば、HTTP サンプルの場合はリモート サーバー) の観点から計算されます。JMeter は、リクエストが生成された合計時間を考慮に入れます。他のサンプラーとタイマーが同じスレッドにある場合、合計時間が増加するため、スループット値が減少します。したがって、名前の異なる 2 つの同一のサンプラーのスループットは、同じ名前の 2 つのサンプラーの半分になります。集計レポートから最良の結果を得るには、サンプラー名を正しく選択することが重要です。

中央値と 90 % ライン (90パーセンタイル⁾ の値の計算には、追加のメモリが必要です。JMeter はサンプルを同じ経過時間で結合するようになったため、使用するメモリがはるかに少なくなりました。ただし、数秒以上かかるサンプルの場合、同じ時間を持つサンプルが少なくなる可能性があり、その場合はより多くのメモリが必要になります。後でこのリスナーを使用して、CSV または XML 結果ファイルをリロードできます。これは、パフォーマンスへの影響を回避するための推奨される方法です。個々のサンプルを保存せず、一定のメモリを必要とする同様のリスナー については、概要レポートを参照してください。

• ラベル- サンプルのラベル。[グループ名をラベルに含めますか? ] を選択すると、スレッド グループの名前がプレフィックスとして追加されます。これにより、必要に応じて、異なるスレッド グループの同一のラベルを個別に照合できます。
• # Samples - 同じラベルを持つサンプルの数
• Average - 一連の結果の平均時間
• 中央値-中央値は、一連の結果の中間にある時間です。サンプルの 50 % は、この時間より長くかかりませんでした。残りは少なくとも同じくらい時間がかかりました。
• 90% ライン- サンプルの 90% がこの時間より長くかからなかった。残りのサンプルは、少なくともこれと同じくらいの時間がかかりました。( 90^{パーセンタイル} )
• 95% ライン- サンプルの 95% は、この時間より長くかかりませんでした。残りのサンプルは、少なくともこれと同じくらいの時間がかかりました。( 95^{パーセンタイル} )
• 99% ライン- サンプルの 99% は、この時間より長くかかりませんでした。残りのサンプルは、少なくともこれと同じくらいの時間がかかりました。( 99^{パーセンタイル} )
• Min - 同じラベルのサンプルの最短時間
• Max - 同じラベルを持つサンプルの最長時間
• エラー % - エラーのあるリクエストの割合
• スループット-スループットは、秒/分/時間あたりのリクエスト数で測定されます。時間単位は、表示されるレートが少なくとも 1.0 になるように選択されます。スループットを CSV ファイルに保存すると、リクエスト/秒で表されます。つまり、30.0 リクエスト/分は 0.5 として保存されます。
• 受信 KB/秒- 1 秒あたりの受信キロバイト数で測定されたスループット
• 送信 KB/秒- 1 秒あたりの送信キロバイト数で測定されたスループット

時間はミリ秒単位です。

デフォルトでは、メイン (親) サンプルのみが表示されます。サブサンプル (子サンプル) は表示されません。JMeter には「Child Samples?」チェックボックスがあります。これを選択すると、メイン サンプルの代わりにサブ サンプルが表示されます。

メーラー ビジュアライザーは、テスト実行がサーバーからあまりにも多くの失敗した応答を受信した場合に電子メールを送信するように設定できます。

BeanShell Listener を使用すると、BeanShell を使用して、保存などのサンプルを処理できます。

BeanShell の使用の詳細については、BeanShell の Web サイトを参照してください。

テスト要素は、ThreadListenerメソッドとTestListenerメソッドをサポートしています。これらは初期化ファイルで定義する必要があります。定義の例 については、ファイルBeanShellListeners.bshrcを参照してください。

スループットは、サンプラ ターゲット (たとえば、HTTP サンプルの場合はリモート サーバー) の観点から計算されます。JMeter は、リクエストが生成された合計時間を考慮に入れます。他のサンプラーとタイマーが同じスレッドにある場合、合計時間が増加するため、スループット値が減少します。したがって、名前の異なる 2 つの同一のサンプラーのスループットは、同じ名前の 2 つのサンプラーの半分になります。レポートから最良の結果を得るには、サンプラー ラベルを正しく選択することが重要です。

• ラベル- サンプルのラベル。[グループ名をラベルに含めますか? ] を選択すると、スレッド グループの名前がプレフィックスとして追加されます。これにより、必要に応じて、異なるスレッド グループの同一のラベルを個別に照合できます。
• # Samples - 同じラベルを持つサンプルの数
• Average - 一連の結果の平均経過時間
• Min - 同じラベルを持つサンプルの最小経過時間
• Max - 同じラベルを持つサンプルの最長経過時間
• 標準 開発者 -サンプル経過時間の標準偏差
• エラー % - エラーのあるリクエストの割合
• スループット-スループットは、秒/分/時間あたりのリクエスト数で測定されます。時間単位は、表示される率が少なくとも1.0になるように選択されます。スループットを CSV ファイルに保存すると、リクエスト/秒で表されます。つまり、30.0 リクエスト/分は0.5として保存されます。
• 受信 KB/秒- キロバイト/秒で測定されたスループット
• 送信 KB/秒- キロバイト/秒で測定されたスループット
• 平均 Bytes - サンプル応答の平均サイズ (バイト単位)。

時間はミリ秒単位です。

このテスト要素は、テスト計画のどこにでも配置できます。スコープ内のサンプルごとに、応答データのファイルが作成されます。これの主な用途は機能テストの作成ですが、応答が大きすぎて 結果ツリーの表示リスナーに表示できない場合にも役立ちます。ファイル名は、指定されたプレフィックスと番号から作成されます (これが無効にされていない限り、以下を参照してください)。ファイル拡張子は、既知の場合、ドキュメント タイプから作成されます。不明な場合、ファイル拡張子は「不明」に設定されます'。ナンバリングが無効で、サフィックスの追加が無効になっている場合、ファイルのプレフィックスがファイル名全体として使用されます。これにより、必要に応じて固定ファイル名を生成できます。生成されたファイル名はサンプル応答に保存され、必要に応じてテスト ログ出力ファイルに保存できます。

現在のサンプルが最初に保存され、その後にサブサンプル (子サンプル) が続きます。変数名が指定されている場合、サブサンプルが表示される順序でファイルの名前が保存されます。下記参照。

JSR223 リスナーを使用すると、JSR223 スクリプト コードをサンプル結果に適用できます。

# 次のプロパティを定義して、その名前のサマライザーを自動的に開始します
# (CLI モードのみに適用)
#summariser.name=要約
#
# サマリー間の間隔 (秒単位) デフォルト 3 分
#summariser.interval=30
#
# ログファイルにメッセージを書き込む
#summariser.log=true
#
# System.out にメッセージを書き込む
#summariser.out=true

label + 16 in 0:00:12 = 1.3/s 平均: 1608 最小: 1163 最大: 2009 エラー: 0 (0.00%) アクティブ: 5 開始: 5 終了: 0
label + 82 in 0:00:30 = 2.7/s 平均: 1518 最小: 1003 最大: 2020 エラー: 0 (0.00%) アクティブ: 5 開始: 5 終了: 0
label = 98 in 0:00:42 = 2.3/s 平均: 1533 最小: 1003 最大: 2020 エラー: 0 (0.00%)
label + 85 in 0:00:30 = 2.8/s 平均: 1505 最小: 1008 最大: 2005 エラー: 0 (0.00%) アクティブ: 5 開始: 5 終了: 0
label = 183 in 0:01:13 = 2.5/s 平均: 1520 最小: 1003 最大: 2020 エラー: 0 (0.00%)
label + 79 in 0:00:30 = 2.7/s 平均: 1578 最小: 1089 最大: 2012 エラー: 0 (0.00%) アクティブ: 5 開始: 5 終了: 0
label = 262 in 0:01:43 = 2.6/s 平均: 1538 最小: 1003 最大: 2020 エラー: 0 (0.00%)
label + 80 in 0:00:30 = 2.7/s 平均: 1531 最小: 1013 最大: 2014 エラー: 0 (0.00%) アクティブ: 5 開始: 5 終了: 0
ラベル = 342 インチ 0:02:12 = 2.6/秒 平均: 1536 最小: 1003 最大: 2020 エラー: 0 (0.00%)
label + 83 in 0:00:31 = 2.7/s 平均: 1512 最小: 1003 最大: 1982 エラー: 0 (0.00%) アクティブ: 5 開始: 5 終了: 0
label = 425 in 0:02:43 = 2.6/s 平均: 1531 最小: 1003 最大: 2020 エラー: 0 (0.00%)
label + 83 in 0:00:29 = 2.8/s 平均: 1487 最小: 1023 最大: 2013 エラー: 0 (0.00%) アクティブ: 5 開始: 5 終了: 0
label = 508 in 0:03:12 = 2.6/s 平均: 1524 最小: 1003 最大: 2020 エラー: 0 (0.00%)
label + 78 in 0:00:30 = 2.6/s 平均: 1594 最小: 1013 最大: 2016 エラー: 0 (0.00%) アクティブ: 5 開始: 5 終了: 0
label = 586 in 0:03:43 = 2.6/s 平均: 1533 最小: 1003 最大: 2020 エラー: 0 (0.00%)
label + 80 in 0:00:30 = 2.7/s 平均: 1516 最小: 1013 最大: 2005 エラー: 0 (0.00%) アクティブ: 5 開始: 5 終了: 0
label = 666 in 0:04:12 = 2.6/s 平均: 1531 最小: 1003 最大: 2020 エラー: 0 (0.00%)
label + 86 in 0:00:30 = 2.9/s 平均: 1449 最小: 1004 最大: 2017 エラー: 0 (0.00%) アクティブ: 5 開始: 5 終了: 0
label = 752 in 0:04:43 = 2.7/s 平均: 1522 最小: 1003 最大: 2020 エラー: 0 (0.00%)
label + 65 in 0:00:24 = 2.7/s 平均: 1579 最小: 1007 最大: 2003 エラー: 0 (0.00%) アクティブ: 0 開始: 5 終了: 5
label = 817 in 0:05:07 = 2.7/s 平均: 1526 最小: 1003 最大: 2020 エラー: 0 (0.00%)

ラベルは、サンプル結果をグループ化するために使用されます。したがって、複数のスレッド グループがあり、それらすべてを要約したい場合は、同じラベルを使用するか、要約をテスト計画に追加します (すべてのスレッド グループがスコープ内にあるようにします)。適切なラベルを使用し、サマライザーをテスト計画の適切な部分に追加することで、さまざまな要約グループを実装できます。

CSV Data Set Config は、ファイルから行を読み取り、それらを変数に分割するために使用されます。__CSVRead()および__StringFromFile()関数よりも使いやすいです。多数の変数の処理に適しており、「ランダムな」値や一意の値を使用したテストにも役立ちます。

実行時に一意のランダム値を生成すると、CPU とメモリの面でコストがかかるため、テストの前にデータを作成してください。必要に応じて、ファイルからの「ランダムな」データを実行時パラメーターと組み合わせて使用​​し、実行時にすべてを生成するよりもはるかに安価な連結などを使用して、実行ごとに異なる値のセットを作成できます。

JMeter では、値を引用できます。これにより、値に区切り文字を含めることができます。" allow quoted data " が有効になっている場合、値を二重引用符で囲むことができます。これらは削除されます。引用符で囲まれたフィールド内に二重引用符を含めるには、2 つの二重引用符を使用します。例えば：

1,"2,3","4""5" =>
1
2,3
4"5

JMeter は、列名を定義するヘッダー行を持つ CSV ファイルをサポートしています。これを有効にするには、「変数名」フィールドを空のままにします。正しい区切り文字を指定する必要があります。

JMeter は、改行を含む引用符付きデータを含む CSV ファイルをサポートしています。

デフォルトでは、ファイルは 1 回だけ開かれ、各スレッドはファイルから異なる行を使用します。ただし、行がスレッドに渡される順序は、スレッドが実行される順序に依存し、反復間で異なる場合があります。各テスト反復の開始時に行が読み取られます。ファイル名とモードは最初の繰り返しで解決されます。

その他のオプションについては、以下の共有モードの説明を参照してください。各スレッドに独自の値のセットを持たせたい場合は、スレッドごとに 1 つのファイルのセットを作成する必要があります。たとえば、test1.csv、test2.csv、…、test n .csv。ファイル名 test${__threadNum}.csvを使用し、「共有モード」を「現在のスレッド」に設定します。

特殊なケースとして、区切りフィールドの文字列 " \t " (引用符なし) はタブとして扱われます。

ファイルの終わり ( EOF ) に達し、リサイクル オプションがtrue の場合、読み取りはファイルの最初の行から再開されます。

recycle オプションがfalseで、stopThread がfalseの場合、ファイルの終わりに到達すると、すべての変数が<EOF>に設定されます。この値は、JMeter プロパティcsvdataset.eofstringを設定することで変更できます。

Recycle オプションがfalseで、Stop Thread がtrue の場合、 EOFに達するとスレッドが停止します。

DNS キャッシュ マネージャー要素を使用すると、ユーザーが異なる IP からコンテンツを受信したときに、ロード バランサー (CDN など) の背後に複数のサーバーがあるアプリケーションをテストできます。デフォルトでは、JMeter は JVM DNS キャッシュを使用します。そのため、クラスタ内の 1 つのサーバーのみが負荷を受けます。DNS キャッシュ マネージャーは、反復ごとに各スレッドの名前を個別に解決し、解決の結果を内部 DNS キャッシュに保存します。これは、JVM と OS の両方の DNS キャッシュから独立しています。

静的ホストのマッピングを使用して、 /etc/hostsファイルなど をシミュレートできます。これらのエントリは、カスタム リゾルバーよりも優先されます。このマッピングを使用する場合は、 [カスタム DNS リゾルバーを使用する] を有効にする必要があります。

Authorization Manager を使用すると、サーバー認証を使用して制限されている Web ページに対して 1 つ以上のユーザー ログインを指定できます。このタイプの認証は、ブラウザを使用して制限されたページにアクセスし、ブラウザにログイン ダイアログ ボックスが表示されたときに表示されます。JMeter は、このタイプのページに遭遇すると、ログイン情報を送信します。

認可ヘッダーは、ツリー ビュー リスナーの[要求] タブに表示されない場合があります。Java 実装はプリエンプティブ認証を行いますが、JMeter がヘッダーをフェッチするときに Authorization ヘッダーを返しません。HttpComponents (HC 4.5.X) 実装は、3.2 以降、デフォルトでプリエンプティブになり、ヘッダーが表示されます。これを無効にするには、以下のように値を設定します。この場合、認証はチャレンジに応じてのみ実行されます。

ファイルjmeter.propertiesでhttpclient4.auth.preemptive=falseを設定します

HTTP キャッシュ マネージャーは、そのスコープ内の HTTP 要求にキャッシュ機能を追加して、ブラウザーのキャッシュ機能をシミュレートするために使用されます。各仮想ユーザー スレッドには独自のキャッシュがあります。デフォルトでは、キャッシュ マネージャーは、LRU アルゴリズムを使用して、仮想ユーザー スレッドごとに最大 5000 個のアイテムをキャッシュに格納します。この値を変更するには、プロパティ「maxSize 」を使用します。この値を大きくするほど、HTTP キャッシュ マネージャーがメモリを消費するので、それに応じて-Xmx JVM オプションを調整してください。

サンプルが成功した場合 (つまり、応答コードが2xxの場合)、Last-ModifiedおよびEtag (関連する場合はExpired ) の値が URL に保存されます。次のサンプルを実行する前に、サンプラーはキャッシュにエントリがあるかどうかを確認し、エントリがある場合は、If-Last-ModifiedおよびIf-None-Match条件ヘッダーが要求に設定されます。

さらに、[ Use Cache-Control/Expires header ] オプションが選択されている場合、Cache-Control / Expiresの値が現在の時間に対してチェックされます。リクエストがGETリクエストで、タイムスタンプが未来の場合、サンプラーはリモート サーバーに URL をリクエストせずにすぐに戻ります。これは、ブラウザの動作をエミュレートすることを目的としています。Cache-Controlヘッダーが「no-cache」の場合、応答は期限切れになる前にキャッシュに保存されるため、条件付きGET要求が生成されることに注意してください。Cache-Controlに他の値がある場合、「max -age" expiry オプションは、エントリの有効期間を計算するために処理されます。欠落している場合は、Expire ヘッダーが使用されます。欠落しているエントリは、RFC 2616 セクション 13.2.4で指定されているようにLast-Modified時刻と応答日付 を使用してキャッシュされます。

Cookie Manager 要素には 2 つの機能があります。1 つ目は
、Web ブラウザと同じように Cookie を保存して送信することです。HTTP 要求があり、応答に Cookie が含まれている場合、Cookie Manager はその Cookie を自動的に保存し、その特定の Web サイトへの今後のすべての要求に使用します。各 JMeter スレッドには、独自の「Cookie ストレージ領域」があります。したがって、セッション情報を保存するために Cookie を使用する Web サイトをテストしている場合、各 JMeter スレッドには独自のセッションがあります。このような Cookie は Cookie Manager 画面には表示されませんが、 View Results Tree Listener を使用して表示できることに注意してください。

JMeter は、受信した Cookie が URL に対して有効であることを確認します。これは、クロスドメイン Cookie が保存されないことを意味します。動作にバグがある場合、またはクロスドメイン Cookie を使用したい場合は、JMeter プロパティ「CookieManager.check.cookies=false」を定義してください。

受信した Cookie は、JMeter スレッド変数として保存できます。Cookie を変数として保存するには、プロパティ「CookieManager.save.cookies=true」を定義します。また、Cookie 名には、保存前に「COOKIE_」というプレフィックスが付けられます (これにより、ローカル変数の偶発的な破損が回避されます)。元の動作に戻すには、プロパティ「CookieManager.name.prefix=」(1 つ以上のスペース) を定義します。有効にすると、TESTという名前の Cookie の値を${COOKIE_TEST}として参照できます。

次に、Cookie マネージャーに Cookie を手動で追加できます。ただし、これを行うと、Cookie はすべての JMeter スレッドで共有されます。

このような Cookie は、かなり先の有効期限で作成されることに注意してください。

デフォルトでは、 null値を 持つ Cookieは無視されます。これは、JMeter プロパティCookieManager.delete_null_cookies=falseを設定することで変更できます。これは、手動で定義された Cookie にも適用されることに注意してください。そのような Cookie は、更新時に表示から削除されます。Cookie 名は一意である必要があることにも注意してください。2 番目の Cookie が同じ名前で定義されている場合、最初の Cookie が置き換えられます。

この要素を使用すると、HTTP 要求コントローラーが使用するデフォルト値を設定できます。たとえば、25 個の HTTP 要求コントローラーを使用してテスト計画を作成し、すべての要求が同じサーバーに送信される場合、「サーバー名または IP」フィールドに入力された単一の HTTP 要求の既定要素を追加できます。 、25 個の HTTP 要求コントローラーを追加するときは、[サーバー名または IP]フィールドを空のままにします。コントローラは、このフィールド値を HTTP Request Defaults 要素から継承します。

ヘッダー マネージャーを使用すると、HTTP 要求ヘッダーを追加またはオーバーライドできます。

JMeter は複数のヘッダー マネージャーをサポートするようになりました。ヘッダー エントリがマージされて、サンプラーのリストが形成されます。マージされるエントリが既存のヘッダー名と一致する場合、以前のエントリが置き換えられます。これにより、ヘッダーのデフォルト セットを設定し、特定のサンプラーに調整を適用できます。ヘッダーの空の値は既存のヘッダーを削除せず、その値を置き換えるだけであることに注意してください。

Java Request Defaults コンポーネントを使用すると、Java テストのデフォルト値を設定できます。Java リクエストを参照してください。

Keystore Config Element を使用すると、キーストアのロード方法と使用するキーを構成できます。このコンポーネントは通常、応答時間でキーストアの初期化を考慮したくない HTTPS シナリオで使用されます。

この要素を使用するには、最初に、テストするクライアント証明書を使用して Java キー ストアをセットアップする必要があります。

1. Java keytoolユーティリティまたは PKI を使用して証明書を作成します
2. PKI によって作成された場合は、キーを JKS で受け入れられる形式に変換して、Java キー ストアにインポートします。
3. 次に、2 つの JVM プロパティを介してキーストア ファイルを参照します (またはsystem.propertiesに追加します)。
   • -Djavax.net.ssl.keyStore=path_to_keystore
   • -Djavax.net.ssl.keyStorePassword=password_of_keystore

ストアのソースとして PKCS11 を使用するには、javax.net.ssl.keyStoreTypeをPKCS11 に、javax.net.ssl.keyStoreをNONEに設定する必要があります。

Login Config Element を使用すると、セットアップの一部としてユーザー名とパスワードを使用するサンプラーで、ユーザー名とパスワードの設定を追加または上書きできます。

LDAP Request Defaults コンポーネントを使用すると、LDAP テストのデフォルト値を設定できます。LDAP リクエストを参照してください。

LDAP Extended Request Defaults コンポーネントを使用すると、拡張 LDAP テストのデフォルト値を設定できます。LDAP 拡張要求を参照してください。

TCP Sampler Config は、TCP Sampler のデフォルト データを提供します。

ユーザー定義変数要素を使用すると、テスト計画と同様に、変数の初期セットを定義できます。

UDV は、呼び出されるたびに異なる結果を生成する関数では使用しないでください。最初の関数呼び出しの結果のみが変数に保存されます。 ただし、UDV は__P() などの関数で使用できます。次に例を示します。

ホスト ${__P(ホスト,localhost)}

これにより、変数「HOST」が JMeter プロパティ「host 」の値を持つように定義され、定義されていない場合は デフォルトで「localhost 」になります。

テスト実行中の変数の定義については、ユーザー パラメータを参照してください。UDV は、プランに表示される順序で上から下に処理されます。

簡単にするために、UDV はスレッド グループの先頭 (またはテスト計画自体の下) にのみ配置することをお勧めします。

テスト計画とすべての UDV が処理されると、変数の結果セットが各スレッドにコピーされ、変数の初期セットが提供されます。

User Parameters Pre-Processor や Regular Expression Extractor などのランタイム要素が UDV 変数の 1 つと同じ名前の変数を定義する場合、これは初期値を置き換え、スレッド内の他のすべてのテスト要素には更新された値が表示されます。価値。

ランダム変数構成要素は、ランダムな数値文字列を生成し、後で使用するために変数に格納するために使用されます。ユーザー定義変数を__Random()関数 と一緒に使用するよりも簡単です。

出力変数は乱数ジェネレーターを使用して作成され、結果の数値は書式文字列を使用して書式設定されます。数値は、式minimum+Random.nextInt(maximum-minimum+1)を使用して計算されます。 Random.nextInt()には正の整数が必要です。これは、maximum-minimum (範囲) が2147483647未満でなければならないことを意味しますが、範囲が OK である限り 、最小値と最大値は任意の長い値にすることができます。

ユーザーは、スレッド グループ内のどこからでも参照できるカウンターを作成できます。カウンター構成により、ユーザーは開始点、最大値、および増分を構成できます。カウンターは最初から最大までループし、最初からやり直して、テストが終了するまで続けます。

カウンターは long を使用して値を格納するため、範囲は-2^63から2^63-1です。

Simple Config Element を使用すると、サンプラーに任意の値を追加またはオーバーライドできます。値の名前と値自体を選択できます。一部の冒険好きなユーザーはこの要素の用途を見つけるかもしれませんが、ここでは主に開発者が新しい JMeter コンポーネントを開発する際に使用できる基本的な GUI として使用します。

次に、このコードを使用して要素MongoDBHolderを介して Beanshell または JSR223 テスト要素のcom.mongodb.DBオブジェクトに アクセスできます。

com.mongodb.DB をインポートします。
org.apache.jmeter.protocol.mongodb.config.MongoDBHolder をインポートします。
DB db = MongoDBHolder.getDBFromSource("MongoDB ソース プロパティの値",
            "プロパティ データベース名の値");
…
    

応答アサーション コントロール パネルでは、要求または応答のさまざまなフィールドと比較するパターン文字列を追加できます。パターン文字列は次のとおりです。

• 含む,一致する : Perl5 スタイルの正規表現
• Equals、Substring : プレーン テキスト、大文字と小文字を区別

パターン マッチング文字の概要は、 ORO Perl5 正規表現 で見つけることができます。

また、文字列が応答全体と一致すると予想されるか、または応答にパターンのみが含まれると予想されるかを選択することもできます。柔軟性を高めるために、複数のアサーションを任意のコントローラーにアタッチできます。

パターン文字列には区切り文字を含めないでください。つまり、/Price: \d+/ではなくPrice: \d+を使用してください。

デフォルトでは、パターンは複数行モードです。つまり、「.」メタ文字は改行と一致しません。複数行モードでは、" ^ " と " $ " は、文字列全体の先頭と末尾だけでなく、文字列内の任意の行の先頭または末尾に一致します。\sは改行に一致することに注意してください。大文字小文字も重要です。これらの設定をオーバーライドするには、拡張正規表現構文を使用できます。例えば：

（？私）

大文字と小文字を区別しない

(?s)

ターゲットを単一行として扱います。つまり、「.」は改行に一致します

（？は）

上記の両方

(?i)りんご(?-i)パイ

" Applee Pie " に一致しますが、" Applee pIe "には一致しません

(?s)Apple.+?Pie

はAppleの後にPieが続くものと一致し、これは後続の行にある場合があります。

Apple(?s).+?Pie

上記と同じですが、最初に(?s)を使用する方がおそらく明確です。

Duration アサーションは、各応答が一定時間内に受信されたことをテストします。指定されたミリ秒数 (ユーザーが指定) よりも長くかかる応答は、失敗した応答としてマークされます。

サイズ アサーションは、各応答に正しいバイト数が含まれていることをテストします。サイズは、特定のバイト数と等しい、より大きい、より小さい、または等しくないことを指定できます。

XML アサーションは、応答データが形式的に正しい XML ドキュメントで構成されていることをテストします。DTD またはスキーマに基づいて XML を検証したり、それ以上の検証を行ったりすることはありません。

BeanShell アサーションにより、ユーザーは BeanShell スクリプトを使用してアサーション チェックを実行できます。

BeanShell の使用の詳細については、BeanShell の Web サイトを参照してください。

テスト スクリプトの各スレッドで独立して発生するアサーションごとに異なるインタープリターが使用されますが、後続の呼び出しには同じインタープリターが使用されることに注意してください。これは、アサーションへの呼び出し間で変数が持続することを意味します。

すべてのアサーションは、サンプラーと同じスレッドから呼び出されます。

プロパティ「beanshell.assertion.init」が定義されている場合、ソース ファイルの名前としてインタープリターに渡されます。これは、共通のメソッドと変数を定義するために使用できます。binディレクトリにサンプルの初期化ファイルがあります: BeanShellAssertion.bshrc

テスト要素は、ThreadListenerメソッドとTestListenerメソッドをサポートしています。これらは初期化ファイルで定義する必要があります。定義の例 については、ファイルBeanShellListeners.bshrcを参照してください。

MD5Hex アサーションにより、ユーザーは応答データの MD5 ハッシュを確認できます。

HTML アサーションにより、ユーザーは JTidy を使用して応答データの HTML 構文を確認できます。

XPath アサーションは、文書の整形性をテストし、DTD に対して検証するか、文書を JTidy に通して XPath をテストするオプションがあります。その XPath が存在する場合、アサーションは true です。「/」を使用すると、整形式のドキュメントと一致し、デフォルトの XPath 式になります。アサーションは、「 count(//*error)=2 」などのブール式もサポートしています。XPath の 詳細については、 http://www.w3.org/TR/xpathを参照してください。

• //title[text()='Text to match'] -応答の任意の場所にある<title>Text to match</title> と一致します
• /title[text()='一致するテキスト'] -応答のルート レベルで<title>一致するテキスト</title> に一致します

XPath2 アサーションは、ドキュメントの整形性をテストします。「/」を使用すると、整形式のドキュメントと一致し、デフォルトの XPath2 式です。アサーションは、「 count(//*error)=2 」などのブール式もサポートしています。

• //title[text()='Text to match'] -応答の任意の場所にある<title>Text to match</title> と一致します
• /title[text()='一致するテキスト'] -応答のルート レベルで<title>一致するテキスト</title> に一致します

XML スキーマ アサーションを使用すると、ユーザーは XML スキーマに対して応答を検証できます。

JSR223 アサーションにより、JSR223 スクリプト コードを使用して前のサンプルのステータスを確認できます。