こんにちは、ハブル！ これは私の続編です ここでは、JMeter を使用してメッセージをキューに配置するためのオプションについて説明します。
私たちは大規模な連邦企業のためにデータ バスを作成しています。 さまざまなリクエスト形式、変換、複雑なルーティング。 テストするには、大量のメッセージをキューに送信する必要があります。 手動による痛みは、すべてのカイロプラクターが対処できるわけではありません。
導入
最初はこの痛みを我慢しなければなりませんでしたが。 すべてはRFHUtilから始まりました。 強力ですが、ぎこちなくて怖い：そうですね、ラスは知っています。
場合によっては不可欠ですが、積極的に使用する場合は徐々に減少します。
これでは便利なテストは不可能です。
JMeter を使用すると、すべてが簡単になります。 マスターして慣れるという最初の段階を経て、楽しいテストができるようになるという希望が芽生え始めました。
私は JMS Publisher および JMS Subscriber サンプラーを積極的に使用しています。 JMS Point-to-Point とは異なり、このペアはより使いやすいように思えました。 たとえば、JMS セレクターのサブスクライバーでは変数を指定できますが、ポイントツーポイントではそれができません (または、この方法があまり明確ではありません)。
サンプラーの準備
JMS パブリッシャー
- セットアップ - 各サンプル。 アパッチ キュー/トピックが変数経由で指定されている場合は、このオプションを使用します。
- 有効期限 (ミリ秒) = 120000。失敗した場合、テスト リクエストは 2 分後にキューから消えます。
- 非永続配信モードを使用しますか? - 真実。 IBM 永続モードにより、突然の障害が発生した場合でも、送信されたメッセージが確実に保存されます。 非永続モードでは交換が高速化されます。 テスト目的では、速度がより重要です。
各パブリッシャーで、サブスクライバーが JMS セレクターで使用する jms プロパティを設定します。 送信ごとに、ユーザー パラメーターのテスト計画要素でランダムな値が生成されます。
こうすることで、正しいメッセージが読まれたことを確認できます。
事前構成された JMS パブリッシャの最後の「空白」:
JMSサブスクライバ
- セットアップ - 各サンプル。 まあ、わかりますね。
- タイムアウト (ミリ秒) = 100000。100 秒待ってもリクエストがキューに到着しない場合は、何か問題が発生したことになります。
- サンプル間で停止しますか? - 真実。
JMS セレクター - 非常に便利 。 最終的な JMS サブスクライバ:
送信メッセージ内のキリル文字を処理する方法。 JMeterではデフォルトでは校正後、曲がって表示されます。 これを回避し、いつでもどこでも偉大で強力なものを楽しむには、次のことを行う必要があります。
- JVM 引数を JMeter の「ランチャー」に追加します。
-Dfile.encoding=UTF-8 - groovy 行で JSR223 ポストプロセッサをサブスクライバーに追加します。
prev.setDataEncoding("UTF-8")
テキストを送信
最も怠惰なオプション。 新しく作成されたテストのデバッグに適しています。 または、少なくとも小さなものを送る必要がある場合。 オプションを選択してください メッセージソース - テキストエリア そして、メッセージの本文をテキスト ブロックに配置します。
ファイル転送
最も一般的なオプション。 ほとんどのシナリオに適しています。 オプションを選択してください メッセージソース - ファイルから フィールドにメッセージへのパスを指定します ファイル - ファイル名:
ファイルをテキストフィールドに転送する
最も汎用性の高いオプション。 ほとんどのシナリオに適しており、XNUMX 番目の送信オプションがない JMS ポイントツーポイントでも使用できます。
バイト配列を渡す
最も難しい選択肢。 歪み、SMS、摂動のない、バイト単位に至るまで確実に正確なリクエストの送信をチェックするのに適しています。 デフォルトの JMeter ではこれを行うことはできません。 確かにこれについては言われました。
だからダウンロードしなければならなかった そして変更します JMS サブスクライバー。
メソッド内で置き換えられる extractContent(..) ライン：
buffer.append(bytesMessage.getBodyLength() + " bytes received in BytesMessage");へ：
byte[] bytes = new byte[(int) bytesMessage.getBodyLength()];
bytesMessage.readBytes(bytes);
try {
buffer.append(new String(bytes, "UTF-8"));
} catch (UnsupportedEncodingException e) {
throw new RuntimeException(e);
}そしてJMeterを再構築しました。
残っているのは、いくつかの JSR223 サンプラーを追加することだけです。 XNUMX つ目は、パブリッシャー/サブスクライバーのペアがランダムなバイトを含む DAT ファイルを作成する前です。
import org.apache.commons.lang3.RandomUtils;
import java.io.File;
import java.io.FileNotFoundException;
import java.io.FileOutputStream;
import java.io.IOException;
vars.put("PATH_TO_BYTES", "C:temprandomBytes.dat");
File RESULT_FILE = new File(vars.get("PATH_TO_BYTES"));
byte[] arr = RandomUtils.nextBytes((int)(Math.random()*10000));
try {
FileOutputStream fos = new FileOutputStream(RESULT_FILE);
fos.write(arr);
fos.close();
} catch (IOException e) {
System.out.println("file not found");
}XNUMX 番目のスクリプトの最後で、ファイルを削除します。
import java.io.File;
File RESULT_FILE = new File(vars.get("PATH_TO_BYTES"));
RESULT_FILE.delete();Publisher でファイルへのパスを追加することを忘れないでください。
また、サブスクライバーの JSR223 アサーションもチェックします。ソース バイトと受信者のキューに到着したバイトを比較します。
import java.nio.file.Files;
import java.nio.file.Path;
import java.nio.file.Paths;
import java.util.Arrays;
Path path = Paths.get(vars.get("PATH_TO_BYTES"), new String[0]);
byte[] originalArray = Files.readAllBytes(path);
byte[] changedArray = ctx.getPreviousResult().getResponseData();
System.out.println(changedArray.length);
if (Arrays.equals(originalArray, changedArray))
{
SampleResult.setResponseMessage("OK");
} else {
SampleResult.setSuccessful(false);
SampleResult.setResponseMessage("Comparison failed");
SampleResult.setResponseData("Bytes have changed","UTF-8");
IsSuccess=false;
}まとめ
私が実際に毎日使用している、キューにメッセージを送信する XNUMX つの方法について説明しました。 この情報があなたの生活を楽にすることを願っています。 続けて、一方の端にキューがあり、もう一方の端にデータベースまたはファイル システムがある交換をテストした経験について話す予定です。
時間を節約しましょう。 ご清聴ありがとうございました。
出所： habr.com