🥇 Черги та JMeter: обмін з Publisher та Subscriber

Привіт, Хабре! Це сіквел моєї попередній публікації, в якому розповім про варіанти розміщення повідомлень у чергах за допомогою JMeter.

Ми робимо шину даних для великої федеральної компанії. Різні формати запитів, перетворення, хитромудра маршрутизація. Для тестування потрібно надсилати багато повідомлень у черзі. Вручну — біль, з яким впорається не кожен мануальник.

Запровадження

Хоча з цим болем доводилося миритися спочатку. Все почалося з RFHUtil. Потужний, але незручний та страшний: Ну, ви знаєте Руса.

Незамінний у деяких випадках, але стабільно падає у разі активного використання.
Зручне тестування з ним неможливе.

З JMeter все полегшало. Після першого етапу з освоєнням і звиканням з'явилася надія на щасливе тестування.

Активно використовую семплери JMS Publisher та JMS Subscriber. На відміну від JMS Point-to-Point, ця парочка здалася зручнішою у роботі. Наприклад, у Subscriber в JMS Selector можна вказати змінну, у Point-to-Point - ні (або цей спосіб не дуже очевидний).

Підготовка семплерів

JMS Publisher

Setup - Each Sample. Apache рекомендує використовувати цю опцію, якщо черги/топики задано через змінні.
Expiration (ms) = 120000. У разі збою тестові запити зникнуть із черги через 2 хвилини.
Use non-persistent delivery mode? - true. IBM стверджує, що persistent mode забезпечує надійне збереження повідомлень, що передаються в разі раптового збою. Та швидший обмін у non-persistent mode. Для тестових цілей важливіша швидкість.

У кожному Publisher задаю jms-властивість, яку Subscriber буде використовувати в JMS Selector. Для кожного надсилання генерується випадкове значення в елементі тест-плану User Parameters:

Тож можна бути впевненим, що прочитано правильне повідомлення.

Підсумкова «болванка» попередньо налаштованого JMS Publisher:

JMS Subscriber

Setup - Each Sample. Ну ви зрозуміли.
Timeout (ms) = 100000. Якщо запит не приходить у чергу після 100 секунд очікування, то щось пішло не так.
Stop between sample? - true.

JMS Selector – досить зручна штука. Підсумковий JMS Subscriber:

Як бути з кирилицею в повідомленнях, що передаються. У JMeter за промовчанням після вичитування вона відображається криво. Щоб цього уникнути і насолоджуватися великим і могутнім завжди та скрізь, потрібно:

Додати в «запускатор» JMeter аргумент JVM:
```
-Dfile.encoding=UTF-8
```
Додати JSR223 PostProcessor в Subscriber з рядком на groovy:
```
prev.setDataEncoding("UTF-8")
```

Передача тексту

Найбільш лінивий варіант. Підходить для налагодження нових тестів. Або для випадків, коли треба відправити хоч щось невелике. Вибрати опцію Message source - Textarea та розмістити тіло повідомлення у текстовому блоці:

передача файлу

Найчастіший варіант. Підходить для більшості сценаріїв. Вибрати опцію Message source - From file та вказати шлях до повідомлення у полі File - Filename:

Передача файлу у текстове поле

Найуніверсальніший варіант. Підходить для більшості сценаріїв + може використовуватися в JMS Point-to-Point, в якому немає другого варіанта відправлення:

Передача байтового масиву

Найскладніший варіант. Підходить для перевірки непогрішно-точної передачі запитів до байта, без спотворень, смс та пертурбації. Зробити це в дефолтному JMeter не вдасться, тут мені однозначно про це сказали.

Тому довелося завантажити вихідники та модифікувати код JMS Subscriber.

Замінив у методі 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 Sampler. Перший – перед парою Publisher/Subscriber для створення 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");
        }

Другий — наприкінці сценарію видаляє файл:

import java.io.File;

File RESULT_FILE = new File(vars.get("PATH_TO_BYTES"));
RESULT_FILE.delete();

І не забути додати шлях до файлу у Publisher:

А також перевірку в JSR223 Assertion для Subscriber - порівняти вихідні байти з тими, що приходять в чергу одержувача:

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;
	}

Висновок

Описав чотири способи надсилання повідомлень у черги, які щодня використовую на практиці. Сподіваюся, що ця інформація полегшить вам життя. Продовжуючи планую розповісти про свій досвід тестування обміну, де на одному кінці — черга, а на іншому — база даних або файлова система.

Бережіть свій час. І дякую за увагу.

Джерело: habr.com

Черги та JMeter: обмін з Publisher та Subscriber