もちろん、私はHabréでJMeterについて最初に書いたわけではありませんが、以前のほとんどすべての記事で、負荷テストに重点を置いています。 これはJMeterのメインアプリケーションですが、その機能はこれらに限定されません。 この製品で使用できるプロトコルを見てみましょう。
- Web-HTTP、HTTPS
- SOAP / REST
- FTP
- JDBC経由のデータベース
- LDAP
- JMSを介したメッセージ指向ミドルウェア(MOM)
- メール-SMTP(S)、POP3(S)およびIMAP(S)
- MongoDB(NoSQL)
- ネイティブコマンドまたはシェルスクリプト
- TCP
したがって、何らかの自動化タスクに直面していて、必要なものがすべてこのリストにリストされている場合は、お気に入りのPerl、Python、またはJavaでプログラミングを始める前に、JMeterの使用を検討する必要があります。 おそらく、このアプローチは多くの時間を節約するでしょう。
設置
これにより、すべてがシンプルになります。
- Javaをインストールします (まだインストールされていない場合)
- 新鮮なJMeterアセンブリを収縮させて開梱します
- JMETER_BIN環境変数をJMeter実行可能ファイルのあるディレクトリに設定します(Windowsのみ)
- binディレクトリからjmeter.batまたはjmeter.sh (オペレーティングシステムに応じて)を実行します。
Windowsで発生した唯一の問題は、JMETER_BIN変数の値がスラッシュまたはバックスラッシュ文字で終了する必要があることです。 詳細は、起動中のスクリプトに記載されています。 指示を読むことも不要ではありません。
スクリプト記録
これはおそらくJMeterの最も素晴らしい機能です。 これについては既に説明しましたが 、繰り返しますが、その記事では少し時代遅れのバージョンについて話していたためです。 JMeterは、すべてのHTTPトラフィックが通過するようにプロキシモードで実行できます。 すべてのインタラクションの詳細は、選択したスレッドグループまたはレコーディングコントローラーに自動的に記録されます 。 ツリーに新しいノードを追加するには、マウスの右ボタンをクリックして、ドロップダウンメニューから必要なタイプを選択するだけです。
テストに使用されるスレッド数やテストのリクエスト数などの設定を制御するスレッドグループは 、 非テスト要素のトレッド(ユーザー)カテゴリ、およびHTTP(S)テストスクリプトレコーダー自体にあります。
図で注意すべき設定を強調表示しました。 8080で既に何かが発生している場合は、ポートを変更する必要がある場合があります。 難しいケースでは、 HTTP Cookie ManagerとHTTP Authorization Managerをテスト計画に追加する必要があります 。 [スタート]ボタンをクリックした後、お気に入りのブラウザーの設定に移動します。
Yandexとの相互作用は、突然、非常に困難になります。
受信したリクエスト( HTTPリクエスト )とその設定( HTTPヘッダーマネージャー )は、誰もが愛用しているコピー&ペーストコマンドを使用して、スクリプト内の任意の場所に転送できます(ドラッグ&ドロップも機能します)。 サイトで何が起こっているのかをしっかりと確信していても、Script Recorderは詳細を調べるのに非常に役立ちます。 さらに、スクリプトの自動生成は、手でスクリプトを操作するよりもはるかに楽しいです。 スクリプト作成プロセスについては、このマニュアルで詳しく説明します 。
変数
多かれ少なかれ深刻なものについては、パラメーター化する能力が必要です。 たとえば、JMeterがサーバーの応答を待機するタイムアウトを設定する必要があるとします。 変更を加えて、すべてのHTTPリクエストにそれらを新たに追加するのは面倒です。 同時に、HTTPプロキシ設定を定義します(使用する場合):
値$ {user_pass}が [パスワード]フィールドでスコア付けされているので、あなたは私の言葉を受け入れなければなりません。 設定自体は、 ユーザー定義変数に保持すると便利です(この要素はConfig要素カテゴリにあります)。
変数の空の値は問題ではありません。 HTTPプロキシを使用しない場合、必要に応じて適切な設定に空白行が置き換えられます。 さらに進んで、すべてのHTTP設定を実際に1つの場所に配置できます。
HTTPリクエストのデフォルト要素とユーザー定義変数は、 構成要素カテゴリにあります。
デバッグ
これで、スクリプトの実行時に何が起こるかを確認できたらうれしいです。 さまざまなタイプのビジュアライザーがリスナーカテゴリに配置されます。 結果ツリーを表示する必要があります 。 それを追加し、 実行/開始コマンド(Ctrl + R)で実行するスクリプトを実行します 。 サーバーの応答も難しいことがわかります。
このような画像は、アドレスが別のページにリダイレクトされた場合に観察され、1つの問題がこれに関連している可能性があります。 サーバーの応答を分析しようとすると(これを行う方法を以下に示します)、(リダイレクトが発生したページの)最後の回答のみが利用可能になります。 前のページの回答も興味深い場合は、自動リダイレクトを無効にする必要があります。 Follow Redirects HTTP Request要素の構成がこれを担当します。 回答を分析すると、ランディングページのアドレスを取得し、2番目のリクエストを手動で実行できます。
スクリプトのデバッグに非常に役立つ別の要素があります。 これはSamplerカテゴリにあり、 Debug Samplerと呼ばれます。 コントロールが彼に来るたびに、彼はすべての変数の現在の値を表示します。 スレッドグループに追加し、スクリプトを再度実行します(前の実行の出力をクリアするには、Ctrl + Eのキーの組み合わせを使用すると便利です)。
すべての変数が完全に表示されます。 便利に。
JDBCリクエスト
このサンプラーは、 JDBCプロトコルをサポートするデータベースへのアクセスを提供します。 まず、データベースサーバーに接続するための設定( JDBC接続構成 )を使用して、構成項目をテスト計画に追加します。
データベースに接続するための実際の設定に加えて、ここで変数名フィールドに入力することが重要です。 この名前は、 JDBCリクエスト ( Sampler )でセッションプールにアクセスするために使用されます。
選択した結果に興味がある場合は、 変数名を入力する必要があります。 JMeter自体は、列名のSQLクエリを解析する方法を知りません。 列名をコンマでリストし、名前を付けずに列をスキップできます。 デバッグサンプラーを挿入し、何が起こったかを確認します。
ドキュメントが嘘をつかないことがわかります。 変数urls_1およびurls_2が表示されました (約束どおり、 urls_#の行数)。 この場所では、注意が必要です。 レコードは一度に1つずつ選択されるのではなく、一度にすべて選択され、1000行以上を読み取った後、簡単に大量のメモリを消費する可能性があります。 ここで、受信したアドレスをループで回避するのは良いことです。
はい、それはまさにトリッキーです。 0から$ {urls_#}のurls変数のセットを選択し 、現在の値をurlに入れます。 ForEach Controller自体は、 Logic Controllerカテゴリにあります。 その中に、パラメーター化されたHTTPリクエストを作成します。 始めます、私たちは見ます:
すべてが機能します。
正規表現
次に、Webサーバーへの呼び出しの結果を分析したいと思います。 これを行うために、 正規表現のフルパワーが与えられます 。 Regular Expression Extractorは、 Post Processorsにあります。 HTTPリクエストに追加して設定します:
ここでは、HTTP応答コードのみに関心があります(ただし、図からわかるように、応答のコンテンツも処理できます)。 一連の数字( 正規表現 )を抽出し、テンプレート( Template )を適用した結果を変数http_result ( Reference Name )に入れます。
予想どおり、200になります。同時に、通常の変数がどのように変数に取り込まれるかを確認できます。
内部の何か
ここで、HTTPリクエストが実行された時間に興味があるとしましょう。 そして、統計だけでなく、スクリプトで何らかの方法で使用したい(たとえば、データベースに追加したい)。 BeanShellはこのタスクを支援します。 具体的には、 PreProcessorおよびPostProcessorsを使用します。
最初にタイムスタンプを受け取ります:
Long t = ctx.getPreviousResult().currentTimeInMillis(); vars.put("timestamp", t.toString());
そして2番目に、それで時間遅延を取得します:
Long d = ctx.getPreviousResult().currentTimeInMillis() - Long.parseLong(vars.get("timestamp")); vars.put("delay", d.toString());
一般に、これも機能します:
しかし、ここで重要な点を指摘しなければなりません。 現時点では、負荷テストを行っていないため、この設計のパフォーマンスは私にとってあまり重要ではありません。 これが当てはまらない場合は、次の記事を読む必要があります 。
打ち上げ
この機会がなかったら、この会話全体を始める価値はありません。 負荷テストの場合、スクリプトはGUIから実行でき、問題ありません。 ただし、自動化に関心がある場合は、サイレントに(たとえばcronで )実行できる必要があります。 もちろん、このような機会があります:
./jmeter.sh -n -t test.jmx -l test.log
スクリプトをjmx拡張子(XML内)を持つファイルに保存し、このコマンドを実行します。 スクリプトはGUIを起動せずに実行され、同時にその作業の結果をログに書き込みます。 すべてがシンプルで便利です。