რიგები და JMeter: გაზიარება გამომცემელთან და აბონენტთან

გამარჯობა, ჰაბრ! ეს ჩემი გაგრძელებაა წინა პუბლიკაცია, რომელშიც მე ვისაუბრებ JMeter-ის გამოყენებით შეტყობინებების რიგებში განთავსების ვარიანტებზე.

ჩვენ ვამზადებთ მონაცემთა ავტობუსს დიდი ფედერალური კომპანიისთვის. მოთხოვნის სხვადასხვა ფორმატები, ტრანსფორმაციები, რთული მარშრუტიზაცია. ტესტირებისთვის, თქვენ უნდა გაგზავნოთ უამრავი შეტყობინება რიგში. ხელით არის ტკივილი, რომელსაც ყველა ქიროპრაქტორი არ შეუძლია გაუმკლავდეს.

შესავალი

მიუხედავად იმისა, რომ თავიდან მომიწია ამ ტკივილის ატანა. ყველაფერი RFHUtil-ით დაიწყო. ძლიერი, მაგრამ უხერხული და საშინელი: კარგად, თქვენ იცით რუსეთი.

ზოგიერთ შემთხვევაში შეუცვლელია, მაგრამ აქტიური გამოყენების შემთხვევაში სტაბილურად მცირდება.
მასთან მოსახერხებელი ტესტირება შეუძლებელია.

JMeter-ით ყველაფერი უფრო ადვილი გახდა. დაუფლებისა და მასთან შეგუების პირველი ეტაპის შემდეგ ბედნიერი ტესტირების იმედი დაიწყო.

მე აქტიურად ვიყენებ JMS Publisher და JMS Subscriber samplers. JMS Point-to-Point-ისგან განსხვავებით, ეს წყვილი უფრო მოსახერხებელი ჩანდა გამოსაყენებლად. მაგალითად, Subscriber-ით JMS Selector-ში შეგიძლიათ მიუთითოთ ცვლადი, მაგრამ Point-to-Point-ით არ შეგიძლიათ (ან ეს მეთოდი არც თუ ისე აშკარაა).

სემპლერების მომზადება

JMS გამომცემელი

• დაყენება - თითოეული ნიმუში. აპაჩი გირჩევთ გამოიყენეთ ეს პარამეტრი, თუ რიგები/თემები მითითებულია ცვლადების მეშვეობით.
• ვადა (ms) = 120000. წარუმატებლობის შემთხვევაში ტესტის მოთხოვნები გაქრება რიგიდან 2 წუთის შემდეგ.
• გსურთ მიწოდების არასტაბილური რეჟიმი? - მართალია. IBM ამტკიცებსრომ მუდმივი რეჟიმი უზრუნველყოფს გადაცემული შეტყობინებების საიმედო შენარჩუნებას უეცარი მარცხის შემთხვევაში. და უფრო სწრაფი გაცვლა არასტაბილურ რეჟიმში. ტესტირების მიზნით, სიჩქარე უფრო მნიშვნელოვანია.

თითოეულ გამომცემელში ვაყენებ jms თვისებას, რომელსაც აბონენტი გამოიყენებს JMS სელექტორში. თითოეული წარდგენისთვის, შემთხვევითი მნიშვნელობა გენერირდება მომხმარებლის პარამეტრების ტესტის გეგმის ელემენტში:

ამ გზით შეგიძლიათ დარწმუნებული იყოთ, რომ სწორი შეტყობინება წაიკითხა.

წინასწარ კონფიგურირებული JMS გამომცემლის საბოლოო „ცარიელი“:

JMS აბონენტი

• დაყენება - თითოეული ნიმუში. აბა, გესმის.
• დროის ამოწურვა (ms) = 100000. თუ მოთხოვნა არ მოვა რიგში ლოდინის 100 წამის შემდეგ, მაშინ რაღაც შეფერხდა.
• შეჩერება ნიმუშებს შორის? - მართალია.

JMS სელექტორი - საკმაოდ მოსახერხებელი რამე. საბოლოო JMS აბონენტი:

როგორ გავუმკლავდეთ კირილიცას გადაცემულ შეტყობინებებში. JMeter-ში, ნაგულისხმევად, კორექტირების შემდეგ, ის უხერხულად არის ნაჩვენები. ამის თავიდან ასაცილებლად და ყოველთვის და ყველგან დიდი და ძლევამოსილით სარგებლობისთვის საჭიროა:

1. დაამატეთ JVM არგუმენტი JMeter „გამშვებს“:

   -Dfile.encoding=UTF-8

2. დაამატეთ JSR223 PostProcessor აბონენტს Groovy ხაზით:

   prev.setDataEncoding("UTF-8")

ტექსტის გაგზავნა

ყველაზე ზარმაცი ვარიანტი. ვარგისია ახლად დაწერილი ტესტების გამართვისთვის. ან იმ შემთხვევისთვის, როცა რაიმე პატარა მაინც უნდა გაგზავნო. აირჩიეთ ვარიანტი შეტყობინების წყარო - Textarea და განათავსეთ შეტყობინების ძირითადი ტექსტი ტექსტურ ბლოკში:

ფაილის გადატანა

ყველაზე გავრცელებული ვარიანტი. შესაფერისია უმეტეს სცენარისთვის. აირჩიეთ ვარიანტი შეტყობინების წყარო - ფაილიდან და მიუთითეთ ველში შეტყობინების გზა ფაილი - ფაილის სახელი:

ფაილის გადატანა ტექსტურ ველში

ყველაზე მრავალმხრივი ვარიანტი. შესაფერისია უმეტეს სცენარისთვის + შეიძლება გამოყენებულ იქნას JMS Point-to-Point-ში, სადაც არ არის გაგზავნის მეორე ვარიანტი:

ბაიტის მასივის გავლა

ყველაზე რთული ვარიანტი. ვარგისია მოთხოვნის უტყუარად ზუსტი გადაცემის შესამოწმებლად ბაიტამდე, დამახინჯების, SMS-ების და აშლილობის გარეშე. თქვენ ვერ შეძლებთ ამის გაკეთებას ნაგულისხმევი JMeter-ში. აქ ამის შესახებ აუცილებლად მითხრეს.

ამიტომ მომიწია გადმოწერა წყაროები და შეცვალე კოდი JMS აბონენტი.

მეთოდით შეიცვალა extractContent(..) ხაზი:

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

on:

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

და აღადგინა JMeter.

რჩება მხოლოდ რამდენიმე JSR223 Sampler-ის დამატება. პირველი არის გამომცემლის/გამომწერის წყვილის წინაშე, რათა შეიქმნას DAT ფაილი, რომელიც შეიცავს შემთხვევით ბაიტებს:

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

მეორე - სკრიპტის ბოლოს, წაშლის ფაილს:

import java.io.File;

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

და არ დაგავიწყდეთ ფაილის ბილიკის დამატება Publisher-ში:

და ასევე შეამოწმეთ JSR223 Assertion for Subscriber - შეადარეთ წყაროს ბაიტები მათთან, რომელიც ჩამოდის მიმღების რიგში:

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

დასკვნა

მე აღვწერე რიგებში შეტყობინებების გაგზავნის ოთხი გზა, რომლებსაც ყოველდღიურად ვიყენებ პრაქტიკაში. ვიმედოვნებ, რომ ეს ინფორმაცია გაგიადვილებთ ცხოვრებას. გაგრძელებაში, მე ვგეგმავ ვისაუბრო გაცვლის ტესტირების გამოცდილებაზე, სადაც არის რიგი ერთ ბოლოში და მონაცემთა ბაზა ან ფაილური სისტემა მეორეზე.

დაზოგეთ თქვენი დრო. და მადლობა ყურადღებისთვის.

წყარო: www.habr.com