🥇Köer och JMeter: utbyte med Publisher och Subscriber

Hej, Habr! Detta är en sequel till min tidigare publicering, där jag kommer att berätta om olika alternativ för att publicera meddelanden i köer med hjälp av JMeter.

Vi skapar en databas för ett stort federalt företag. Olika begäran format, transformationer, komplicerad routing. För testning behöver vi skicka många meddelanden till köer. Att göra det manuellt är en plåga, vilket inte alla manualhanterare klarar av.

Introduktion

Även om man fick uthärda denna smärta i början. Allt började med RFHUtil. Kraftfull, men obekväm och skrämmande: Ni vet ju vem Руса.

Oersättlig i vissa fall, men kraschar konsekvent vid aktiv användning.
Bekväm testning med den är omöjlig.

Med JMeter blev allt enklare. Efter första steget med att lära sig och vänja sig, tändes hoppet för lyckad testning.

Jag använder aktivt JMS Publisher och JMS Subscriber. Till skillnad från JMS Point-to-Point, verkar denna duo vara mer bekväm i arbetet. Till exempel, hos Subscriber i JMS Selector kan man ange en variabel, hos Point-to-Point går det inte (eller så är denna metod inte så uppenbar).

Förberedelse av samplers

JMS Publisher

Setup — Varje exempel. Apache rekommenderar använda detta alternativ om köerna/topicarna sätts via variabler.
Expiration (ms) = 120000. Vid ett misslyckande kommer de testbegärningar som skickats att försvinna från kön efter 2 minuter.
Använd icke-beständig leveransläge? — sant. IBM hävdar, att beständigt läge säkerställer tillförlitlig lagring av överförda meddelanden vid plötsligt fel. Och snabbare utbyte i icke-beständigt läge. För teständamål är hastighet viktigare.

I varje Publisher ställer jag in jms-egenskapen som Subscriber kommer att använda i JMS Selector. För varje sändning genereras ett slumpmässigt värde i testplanens User Parameters:

Så kan man vara säker på att rätt meddelande lästs.

Den slutliga "dummy" av den förinställda JMS Publisher:

JMS Subscriber

Setup — Varje exempel. Ni förstår.
Timeout (ms) = 100000. Om begäran inte anländer till kön efter 100 sekunders väntan, betyder det att något gått fel.
Stopp mellan exempel? — sant.

JMS Selector — ganska praktisk sak. Den slutliga JMS Subscriber:

Hur hantera kyrilliska tecken i skickade meddelanden. I JMeter visas de som standard snett när de läses. För att undvika detta och njuta av den stora och mäktiga alltid och överallt, måste man:

Lägga till ett JVM-argument i "startaren" JMeter:
```
-Dfile.encoding=UTF-8
```
Lägg till JSR223 PostProcessor i Subscriber med raden i groovy:
```
prev.setDataEncoding("UTF-8")
```

Överföring av text

Det mest latenta alternativet. Passar för att göra fel sökningar av nyss skrev tester. Antingen för situationer där man behöver skicka något litet. Välj alternativ Meddelande källa — Textarea och placera meddelandets kropp i textblocket:

Filöverföring

Det vanligaste alternativet. Passar för de flesta scenarier. Välj alternativ Meddelande källa — Från fil och ange sökvägen till meddelandet i fältet Fil — Filnamn:

Filöverföring i textfältet

Det mest universella alternativet. Passar för de flesta scenarier + kan användas i JMS Point-to-Point, där det inte finns något andra överföringsalternativ:

Överföring av byte-array

Det mest komplexa alternativet. Passar för att kontrollera felfri överföring av förfrågningar till byte, utan förvrängning, sms och störningar. Detta kan inte göras i standard JMeter, här det blev uttalat för mig.

Därför var jag tvungen att ladda ner källkod och modifiera kod JMS Subscriber.

Jag ersatte i metoden extractContent(..) raden:

buffer.append(bytesMessage.getBodyLength() + " bytes received in BytesMessage");

till:

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

och byggde om JMeter.

Bara att lägga till ett par JSR223 Sampler. Första — före paret Publisher/Subscriber för att skapa DAT-fil som innehåller slumpmässiga byte:

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

Den andra — i slutet av scenariot, tar bort filen:

import java.io.File;

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

Och glöm inte att lägga till sökvägen till filen vid Publisher:

Samt kontroll i JSR223 Assertion för Subscriber — jämför de ursprungliga bytena med dem som kommer till mottagarens kö:

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("Jämförelsen misslyckades");
	   SampleResult.setResponseData("Byten har ändrats","UTF-8");
     	   IsSuccess=false;
	}

Slutsats

Jag har beskrivit fyra sätt att skicka meddelanden i köer som jag använder i praktiken varje dag. Jag hoppas att denna information gör ditt liv enklare. Framöver planerar jag att berätta om mina erfarenheter av att testa utbyten, där det i ena änden är en kö och i den andra en databas eller filsystem.

Spara din tid. Och tack för din uppmärksamhet.

Källa: habr.com