Чэргі і 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: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