Очереди и 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 по умолчанию после вычитывания она отображается криво. Чтобы этого избежать и наслаждаться великим и могучим всегда и везде, нужно:

1. Добавить в «запускатор» JMeter аргумент JVM:

   -Dfile.encoding=UTF-8
   

2. Добавить 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:\\temp\\randomBytes.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;
        }

Заключение

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

Берегите своё время. И спасибо за внимание.

Let's block ads! (Why?)