Kolejki i JMeter: udostępnianie wydawcy i subskrybentowi

Witaj, Habro! To jest kontynuacja mojej poprzednia publikacja, w którym opowiem o możliwościach umieszczania wiadomości w kolejkach za pomocą JMeter.

Wykonujemy magistralę danych dla dużej firmy federalnej. Różne formaty żądań, transformacje, skomplikowany routing. Aby przetestować, musisz wysłać wiele wiadomości do kolejki. Ręczne wykonywanie zabiegów ręcznych to ból, z którym nie każdy kręgarz sobie poradzi.

Wprowadzenie

Chociaż na początku musiałam znosić ten ból. Wszystko zaczęło się od RFHUtil. Potężny, ale niezręczny i straszny: Cóż, znasz Rusa.

W niektórych przypadkach niezbędny, ale w przypadku aktywnego użytkowania stale maleje.
Wygodne testowanie jest przy nim niemożliwe.

Dzięki JMeter wszystko stało się łatwiejsze. Po pierwszym etapie opanowywania i przyzwyczajania zaczęła świtać nadzieja na szczęśliwe testowanie.

Aktywnie korzystam z samplerów JMS Publisher i JMS Subscriber. W przeciwieństwie do JMS Point-to-Point, ta para wydawała się wygodniejsza w użyciu. Na przykład za pomocą Subskrybenta w Selektorze JMS możesz określić zmienną, ale w przypadku Point-to-Point nie można (lub ta metoda nie jest zbyt oczywista).

Przygotowanie próbników

Wydawnictwo JMS

• Konfiguracja — każda próbka. Apacz poleca użyj tej opcji, jeśli kolejki/tematy są określone poprzez zmienne.
• Wygaśnięcie (ms) = 120000. W przypadku niepowodzenia żądania testowe znikną z kolejki po 2 minutach.
• Użyć nietrwałego trybu dostarczania? - PRAWDA. IBM-a zatwierdzaten tryb trwały zapewnia niezawodne zachowanie przesyłanych wiadomości w przypadku nagłej awarii. I szybsza wymiana w trybie nietrwałym. Dla celów testowych ważniejsza jest prędkość.

W każdym wydawcy ustawiam właściwość jms, której subskrybent będzie używał w selektorze JMS. Dla każdego zgłoszenia generowana jest losowa wartość w elemencie planu testowania parametrów użytkownika:

Dzięki temu będziesz mieć pewność, że przeczytana zostanie właściwa wiadomość.

Ostatnie „puste” miejsce wstępnie skonfigurowanego JMS Publisher:

Abonent JMS

• Konfiguracja — każda próbka. Cóż, rozumiesz.
• Limit czasu (ms) = 100000. Jeśli żądanie nie pojawi się w kolejce po 100 sekundach oczekiwania, oznacza to, że coś poszło nie tak.
• Zatrzymać się między próbkami? - PRAWDA.

Selektor JMS - całkiem wygodny rzecz. Ostateczny subskrybent JMS:

Jak postępować z cyrylicą w przesyłanych wiadomościach. W JMeter domyślnie po korekcie wyświetla się krzywo. Aby tego uniknąć i cieszyć się tym, co wielkie i potężne, zawsze i wszędzie, musisz:

1. Dodaj argument JVM do „programu uruchamiającego” JMeter:

   -Dfile.encoding=UTF-8

2. Dodaj postprocesor JSR223 do subskrybenta za pomocą świetnej linii:

   prev.setDataEncoding("UTF-8")

Wyslij wiadomość

Najbardziej leniwa opcja. Nadaje się do debugowania świeżo napisanych testów. Lub w przypadkach, gdy musisz wysłać przynajmniej coś małego. Wybierz opcję Źródło wiadomości - Textarea i umieść treść wiadomości w bloku tekstowym:

Przesyłanie plików

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

Przesyłanie pliku do pola tekstowego

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

Przekazywanie tablicy bajtów

Najtrudniejsza opcja. Nadaje się do sprawdzania nieomylnie dokładnej transmisji żądań co do bajtu, bez zniekształceń, SMS-ów i zakłóceń. Nie będziesz mógł tego zrobić w domyślnym JMeterze. tutaj Na pewno mi o tym powiedziano.

Musiałem więc pobrać źródła i modyfikować kod Abonent JMS.

Zastąpione w metodzie extractContent(..) linia:

buffer.append(bytesMessage.getBodyLength() + " bytes received in 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 przebudowany JMeter.

Pozostaje tylko dodać kilka samplerów JSR223. Pierwsza następuje przed parą wydawca/subskrybent w celu 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("file not found");
        }

Drugi - na końcu skryptu 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 programie Publisher:

A także sprawdź asercję JSR223 dla subskrybenta - porównaj bajty źródłowe z tymi, które docierają 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("Comparison failed");
	   SampleResult.setResponseData("Bytes have changed","UTF-8");
     	   IsSuccess=false;
	}

wniosek

Opisałem cztery sposoby wysyłania wiadomości do kolejek, z których korzystam na co dzień w praktyce. Mam nadzieję, że te informacje ułatwią Ci życie. Kontynuując, planuję opowiedzieć o moich doświadczeniach z testowania giełdy, w której na jednym końcu znajduje się kolejka, a na drugim baza danych lub system plików.

Oszczędź swój czas. I dziękuję za uwagę.

Źródło: www.habr.com