Очереди и 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;
    	}

    Заключение


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

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

    image

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 5

      0
      JAVA Ад
        +1
        Всё началось с RFHUtil. Мощный, но неудобный и страшный: Ну вы знаете Руса.

        Есть такая приблуда как WMQTools. Написан давно каким-то хакером на Java. На порядки более удобоваримое, нежели RFHUtil. А последний, как впрочем и все от IBM — сделано не для людей.


        P.S. Как сказал чел на первой картинке: "MQ вы… ет и высушит".

          0
          при всем уважении, это не полезная статья, а скорее вредная.
          зачем было городить такой огород? описывайте всю логику в JSR223
          PS. уж про синхронное тестирование я вообще молчу
            0
            Я не мог в Java, когда начал заниматься этим тестированием. А легкости бытия хотелось невыносимо. В следующих реинкарнациях тестов планирую использовать gatling.
              0

              На груви вполне нативно, стандартной документации хватает.
              Вам же потом поддерживать проще будет)

          Only users with full accounts can post comments. Log in, please.