Hallo, Habr! Dit is een vervolg op de mijne , waarin ik het zal hebben over opties voor het plaatsen van berichten in wachtrijen met behulp van JMeter.
We maken een databus voor een groot federaal bedrijf. Verschillende aanvraagformaten, transformaties, ingewikkelde routing. Om te testen moet je veel berichten naar de wachtrij sturen. Handmatig is een pijn die niet iedere chiropractor aankan.
Introductie
Hoewel ik deze pijn eerst moest verdragen. Het begon allemaal met RFHUtil. Krachtig, maar ongemakkelijk en eng: Nou, je kent Rus.
In sommige gevallen onmisbaar, maar bij actief gebruik gestaag afnemend.
Handig testen is er onmogelijk mee.
Met JMeter is alles eenvoudiger geworden. Na de eerste fase van het beheersen en wennen, begon de hoop te dagen op een gelukkige test.
Ik maak actief gebruik van de JMS Publisher en JMS Subscriber samplers. In tegenstelling tot JMS Point-to-Point leek dit paar handiger in gebruik. Met Subscriber in JMS Selector kun je bijvoorbeeld een variabele opgeven, maar met Point-to-Point niet (of deze methode is niet erg voor de hand liggend).
Monsternemers voorbereiden
JMS-uitgever
- Opstelling - Elk monster. Apache gebruik deze optie als wachtrijen/onderwerpen worden gespecificeerd via variabelen.
- Vervaldatum (ms) = 120000. Bij een storing verdwijnen testaanvragen na 2 minuten uit de wachtrij.
- Niet-persistente bezorgingsmodus gebruiken? - WAAR. IBM die persistente modus zorgt voor een betrouwbare bewaring van verzonden berichten in geval van een plotselinge storing. En snellere uitwisseling in niet-persistente modus. Voor testdoeleinden is snelheid belangrijker.
In elke uitgever stel ik een jms-eigenschap in die de abonnee zal gebruiken in de JMS Selector. Voor elke inzending wordt een willekeurige waarde gegenereerd in het testplanelement Gebruikersparameters:
Zo weet u zeker dat het juiste bericht wordt gelezen.
De laatste “blanco” van een vooraf geconfigureerde JMS Publisher:
JMS-abonnee
- Opstelling - Elk monster. Nou, je begrijpt het.
- Time-out (ms) = 100000. Als het verzoek na 100 seconden wachten niet in de wachtrij arriveert, is er iets misgegaan.
- Stoppen tussen monsters? - WAAR.
JMS Selector - best handig . Laatste JMS-abonnee:
Hoe om te gaan met het Cyrillische alfabet in verzonden berichten. In JMeter wordt het na het proeflezen standaard scheef weergegeven. Om dit te vermijden en altijd en overal van het grote en krachtige te genieten, moet je:
- Voeg een JVM-argument toe aan het JMeter-opstartprogramma:
-Dfile.encoding=UTF-8 - Voeg JSR223 PostProcessor toe aan abonnee met een groovy regel:
prev.setDataEncoding("UTF-8")
Stuur tekst
De meest luie optie. Geschikt voor het debuggen van nieuw geschreven toetsen. Of voor gevallen waarin u in ieder geval iets kleins moet versturen. Selecteer optie Berichtbron - Tekstgebied en plaats de hoofdtekst van het bericht in een tekstblok:
Bestandsoverdracht
De meest voorkomende optie. Geschikt voor de meeste scenario's. Selecteer optie Berichtbron - Uit bestand en geef het pad naar het bericht in het veld aan Bestand - Bestandsnaam:
Een bestand overbrengen naar een tekstveld
De meest veelzijdige optie. Geschikt voor de meeste scenario's + kan worden gebruikt in JMS Point-to-Point waar geen tweede verzendoptie is:
Een byte-array doorgeven
De moeilijkste optie. Geschikt voor het controleren van de feilloos nauwkeurige overdracht van verzoeken tot op de byte, zonder vervorming, sms en verstoring. U kunt dit niet doen in de standaard JMeter. Hierover is mij zeker verteld.
Dus ik moest downloaden en wijzigen JMS-abonnee.
Vervangen in de methode extractContent(..) lijn:
buffer.append(bytesMessage.getBodyLength() + " bytes received in BytesMessage");Aan:
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);
}en herbouwd JMeter.
Het enige dat overblijft is het toevoegen van een paar JSR223 Samplers. De eerste is voordat het uitgever/abonnee-paar een DAT-bestand met willekeurige bytes maakt:
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");
}De tweede - aan het einde van het script verwijdert het bestand:
import java.io.File;
File RESULT_FILE = new File(vars.get("PATH_TO_BYTES"));
RESULT_FILE.delete();En vergeet niet het pad naar het bestand in Publisher toe te voegen:
En ook een controle in JSR223 Assertion for Subscriber - vergelijk de bronbytes met de bytes die in de wachtrij van de ontvanger aankomen:
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;
}Conclusie
Ik heb vier manieren beschreven om berichten naar wachtrijen te sturen, die ik in de praktijk dagelijks gebruik. Ik hoop dat deze informatie uw leven gemakkelijker maakt. In het vervolg wil ik het hebben over mijn ervaring met het testen van een uitwisseling waarbij aan de ene kant een wachtrij staat en aan de andere kant een database of bestandssysteem.
Bespaar tijd. En bedankt voor uw aandacht.
Bron: www.habr.com