🥇Warteschlangen und JMeter: Austausch mit Publisher und Subscriber

Hallo, Habr! Dies ist die Fortsetzung meiner vorherigen Beitrag, in der ich die Optionen für das Platzieren von Nachrichten in Warteschlangen mit JMeter erläutere.

Wir entwickeln eine Datenplattform für ein großes Bundesunternehmen. Verschiedene Anfrageformate, Transformationen, komplexe Routenführung. Zum Testen müssen viele Nachrichten in Warteschlangen gesendet werden. Manuell – das ist eine mühsame Aufgabe, die nicht jeder manuelle Tester bewältigen kann.

Einführung

Anfangs musste ich mich jedoch mit diesem Problem arrangieren. Es begann mit RFHUtil. Leistungsstark, aber unhandlich und furchterregend: Ihr kennt Russo.

Unverzichtbar in einigen Fällen, aber es stürzt bei aktiver Nutzung regelmäßig ab.
Bequemes Testen war damit unmöglich.

Mit JMeter wurde alles einfacher. Nach der ersten Phase des Einarbeitens und Gewöhnens kam die Hoffnung auf ein erfolgreiches Testen.

Ich benutze aktiv die Sampler JMS Publisher und JMS Subscriber. Im Gegensatz zu JMS Point-to-Point erschien mir dieses Duo benutzerfreundlicher. Zum Beispiel kann beim Subscriber im JMS Selector eine Variable angegeben werden, beim Point-to-Point jedoch nicht (oder dieser Ansatz ist nicht sehr offensichtlich).

Vorbereitung der Sampler

JMS Publisher

Einrichten – Jeder Sample. Apache empfiehlt verwenden Sie diese Option, wenn Warteschlangen/Themen über Variablen definiert sind.
Ablauf (ms) = 120000. Bei einem Fehler verschwinden die Testanfragen nach 2 Minuten aus der Warteschlange.
Soll der nicht persistente Liefermodus verwendet werden? — true. IBM behauptet, dass der persistente Modus eine zuverlässige Speicherung der übermittelten Nachrichten im Falle eines unerwarteten Ausfalls gewährleistet. Und einen schnelleren Austausch im nicht persistente Modus. Für Testzwecke ist Geschwindigkeit wichtiger.

In jedem Publisher lege ich die JMS-Eigenschaft fest, die der Subscriber im JMS-Selector verwenden wird. Für jede Sendung wird ein zufälliger Wert im Element Testplan Benutzerparameter generiert:

So kann man sicherstellen, dass die richtige Nachricht gelesen wird.

Die endgültige 'Vorlage' des vorkonfigurierten JMS Publishers:

JMS Subscriber

Setup — Jede Probe. Sie haben verstanden.
Timeout (ms) = 100000. Wenn die Anfrage nach 100 Sekunden Wartezeit nicht in der Warteschlange ankommt, ist etwas schiefgelaufen.
Zwischen den Proben anhalten? — true.

JMS-Selector — eine ziemlich praktische Sache.Der finale JMS Subscriber:

Wie geht man mit kyrillischen Zeichen in den übermittelten Nachrichten um? In JMeter wird dies standardmäßig nach dem Lesen fehlerhaft angezeigt. Um dies zu vermeiden und die große und mächtige zu jeder Zeit und überall zu genießen, muss man:

Dem JMeter-Launcher das JVM-Argument hinzufügen:
```
-Dfile.encoding=UTF-8
```
Fügen Sie dem Subscriber einen JSR223 PostProcessor mit der Zeile in Groovy hinzu:
```
prev.setDataEncoding("UTF-8")
```

Textübertragung

Die faulste Option. Geeignet für das Debugging frisch geschriebener Tests. Oder wenn Sie etwas Kleines senden müssen. Wählen Sie die Option aus Nachrichtenquelle — Textbereich und den Nachrichtentext in das Textfeld einfügen:

Dateiübertragung

Die häufigste Option. Geeignet für die meisten Szenarien. Wählen Sie die Option aus Nachrichtenquelle — Aus Datei und den Pfad zur Nachricht im Feld angeben. Datei — Dateiname:

Dateiübertragung im Textfeld

Die universellste Option. Geeignet für die meisten Szenarien + kann in JMS Point-to-Point verwendet werden, wo keine zweite Sendemöglichkeit vorhanden ist:

Übertragung eines Byte-Arrays

Die komplizierteste Option. Geeignet, um die präzise Übertragung von Anfragen bis zum Byte ohne Verzerrungen, SMS und Störungen zu überprüfen. Dies lässt sich im Standard-JMeter nicht umsetzen, hier das wurde mir eindeutig gesagt.

Deshalb musste ich die Quellcodes herunterladen und Code den JMS Subscriber modifizieren.

Ich habe in der Methode extractContent(..) die Zeile ersetzt:

buffer.append(bytesMessage.getBodyLength() + " Bytes in BytesMessage empfangen");

durch:

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

und JMeter neu kompiliert.

Fügen Sie ein paar JSR223-Sampler hinzu. Der erste – vor dem Publisher/Subscriber-Paar, um eine DAT-Datei zu erstellen, die zufällige Bytes enthält:

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("Datei nicht gefunden");
        }

Der zweite – am Ende des Skripts, entfernt die Datei:

import java.io.File;

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

Und vergessen Sie nicht, den Pfad zur Datei beim Publisher hinzuzufügen:

Ebenso eine Überprüfung im JSR223 Assertion für den Subscriber – vergleichen Sie die ursprünglichen Bytes mit denen, die in der Empfangsqueue ankommen:

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("Vergleich fehlgeschlagen");
	   SampleResult.setResponseData("Bytes haben sich geändert","UTF-8");
     	   IsSuccess=false;
	}

Fazit

Ich habe vier Methoden zur Nachrichtenübermittlung in Warteschlangen beschrieben, die ich täglich in der Praxis nutze. Ich hoffe, diese Informationen erleichtern Ihnen das Leben. In Zukunft plane ich, über meine Erfahrungen mit dem Testen von Austauschvorgängen zu berichten, bei denen auf der einen Seite eine Warteschlange und auf der anderen eine Datenbank oder ein Dateisystem steht.

Schützen Sie Ihre Zeit. Vielen Dank für Ihre Aufmerksamkeit.

Quelle: habr.com