🥇Kolejki i JMeter: wymiana z Publisher i Subscriber

Witaj, Habr! To sequele mojej poprzedniej publikacji, w którym opowiem o sposobach umieszczania komunikatów w kole za pomocą JMeter.

Robimy szynę danych dla dużej firmy federalnej. Różne formaty zapytań, transformacje, skomplikowane routingi. Do testowania trzeba wysyłać dużo komunikatów do kolejek. Ręczne wykonanie to ból, z którym nie każdy manualista da sobie radę.

Wprowadzenie

Chociaż z tym bólem trzeba było się zmagać na początku. Wszystko zaczęło się od RFHUtil. Potężny, ale niewygodny i przerażający: No, znacie Ruska.

Niezastąpiony w niektórych przypadkach, ale regularnie zawodzi przy aktywnym użytkowaniu.
Wygodne testowanie z nim jest niemożliwe.

Z JMeter wszystko stało się prostsze. Po pierwszym etapie nauki i przyzwyczajenia pojawiła się nadzieja na szczęśliwe testowanie.

Aktywnie używam sampli JMS Publisher i JMS Subscriber. W przeciwieństwie do JMS Point-to-Point, ta parka wydaje się być wygodniejsza w pracy. Na przykład, w Subscriberze w JMS Selector można określić zmienną, a w Point-to-Point — nie (albo ten sposób nie jest zbyt oczywisty).

Przygotowanie samplerów

JMS Publisher

Setup — Each Sample. Apache zaleca użyj tej opcji, jeśli kolejki/topiki są zadane przez zmienne.
Expiration (ms) = 120000. W przypadku awarii testowe zapytania znikną z kolejki po 2 minutach.
Czy użyć trybu dostawy niepersistent? — true. IBM twierdzi, ponieważ tryb persistent zapewnia niezawodne przechowywanie przesyłanych komunikatów w przypadku nagłej awarii. A szybsza wymiana w trybie non-persistent. Dla celów testowych ważniejsza jest szybkość.

W każdym Publisherze określam właściwość jms, którą Subscriber będzie używał w JMS Selector. Dla każdej wysyłki generowana jest losowa wartość w elemencie planu testu User Parameters:

W ten sposób można być pewnym, że odebrane zostało poprawne wiadomość.

Ostateczna "szablon" wstępnie skonfigurowanego JMS Publishera:

JMS Subscriber

Setup — Each Sample. No, rozumiesz.
Timeout (ms) = 100000. Jeśli zapytanie nie pojawi się w kolejce po 100 sekundach oczekiwania, oznacza to, że coś poszło nie tak.
Czy zatrzymać pomiędzy samplami? — true.

JMS Selector — dość wygodna rzecz. Ostateczny JMS Subscriber:

Jak poradzić sobie z cyrylicą w przesyłanych komunikatach. W JMeter domyślnie po odczycie wyświetla się krzywo. Aby tego uniknąć i cieszyć się wielkim i potężnym zawsze i wszędzie, trzeba:

Dodać do "launchatora" JMeter argument JVM:
```
-Dfile.encoding=UTF-8
```
Dodać JSR223 PostProcessor do Subscriber z linijką w groovy:
```
prev.setDataEncoding("UTF-8")
```

Przesyłanie tekstu

Najbardziej leniwa opcja. Nadaje się do debugowania nowo napisanych testów. Lub w przypadkach, gdy trzeba wysłać cokolwiek niewielkiego. Wybierz opcję Źródło wiadomości — Obszar tekstowy i umieścić treść wiadomości w bloku tekstowym:

Przekazywanie pliku

Najczęstsza opcja. Nadaje się do większości scenariuszy. Wybierz opcję Źródło wiadomości — Z pliku i określić ścieżkę do wiadomości w polu Plik — Nazwa pliku:

Przekazywanie pliku w polu tekstowym

Najbardziej uniwersalna opcja. Nadaje się do większości scenariuszy + może być używana w JMS Point-to-Point, w którym nie ma drugiej opcji wysyłania:

Przekazywanie tablicy bajtów

Najbardziej złożona opcja. Nadaje się do weryfikacji absolutnie precyzyjnego przekazywania zapytań do bajta, bez zniekształceń, SMS-ów i perturbacji. Nie da się tego zrobić w domyślnym JMeterze, tutaj wyraźnie mi to powiedziano.

Dlatego musiałem pobrać źródła i zmodyfikować kod JMS Subscriber.

Zamieniłem w metodzie extractContent(..) linijkę:

buffer.append(bytesMessage.getBodyLength() + " bajtów odebranych w BytesMessage");

na:

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

i zbudowałem JMeter ponownie.

Teraz trzeba dodać kilka Samplerów JSR223. Pierwszy — przed parą Publisher/Subscriber do utworzenia pliku DAT, zawierającego losowe bajty:

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("plik nie został znaleziony");
        }

Drugi — na końcu scenariusza, usuwa plik:

import java.io.File;

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

I nie zapomnij dodać ścieżki do pliku w Publisherze:

A także sprawdzenia w JSR223 Assertion dla Subscriber — porównać oryginalne bajty z tymi, które przychodzą do kolejki odbiorcy:

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("Porównanie nie powiodło się");
		SampleResult.setResponseData("Bajty się zmieniły","UTF-8");
		IsSuccess=false;
	}

Podsumowanie

Opisałem cztery sposoby wysyłania wiadomości w kolejce, które codziennie stosuję w praktyce. Mam nadzieję, że ta informacja ułatwi Ci życie. W przyszłości planuję opowiedzieć o swoim doświadczeniu w testowaniu wymiany, gdzie z jednej strony znajduje się kolejka, a z drugiej - baza danych lub system plików.

Chroń swój czas. Dziękuję za uwagę.

Źródło: habr.com