Hej, Habr! Dette er en efterfølger til min tidligere udgivelse, hvor jeg vil tale om muligheder for at placere beskeder i køer ved hjælp af JMeter.
Vi laver en databus til et stort føderalt firma. Forskellige anmodningsformater, transformationer, indviklet routing. For at teste skal du sende en masse beskeder til køen. Manuelt er en smerte, som ikke enhver kiropraktor kan håndtere.
Indledning
Selvom jeg først måtte finde ud af denne smerte. Det hele startede med RFHUtil. Kraftig, men akavet og skræmmende: Nå, du kender Rus.
Uundværlig i nogle tilfælde, men støt faldende ved aktiv brug.
Praktisk test er umuligt med det.
Med JMeter er alt blevet nemmere. Efter den første fase med at mestre og vænne sig til det, begyndte håbet at gry om en glad test.
Jeg bruger aktivt JMS Publisher og JMS Subscriber samplere. I modsætning til JMS Point-to-Point virkede dette par mere bekvemt at bruge. For eksempel kan du med Subscriber i JMS Selector angive en variabel, men med Point-to-Point kan du ikke (eller denne metode er ikke særlig indlysende).
Forberedelse af prøveudtagere
JMS Forlag
Opsætning - hver prøve. Apache anbefaler brug denne mulighed, hvis køer/emner er angivet via variable.
Udløb (ms) = 120000. I tilfælde af fejl forsvinder testanmodninger fra køen efter 2 minutter.
Vil du bruge ikke-vedvarende leveringstilstand? - rigtigt. IBM fordringerat persistent tilstand sikrer pålidelig bevaring af transmitterede meddelelser i tilfælde af en pludselig fejl. Og hurtigere udveksling i ikke-vedvarende tilstand. Til testformål er hastighed vigtigere.
I hver Publisher indstiller jeg en jms-egenskab, som abonnenten vil bruge i JMS-vælgeren. For hver indsendelse genereres en tilfældig værdi i testplanelementet Brugerparametre:
På denne måde kan du være sikker på, at den korrekte besked bliver læst.
Den sidste "blank" af en forudkonfigureret JMS Publisher:
JMS abonnent
Opsætning - hver prøve. Nå, du forstår.
Timeout (ms) = 100000. Hvis anmodningen ikke kommer i køen efter 100 sekunders venten, så gik der noget galt.
Stop mellem prøverne? - rigtigt.
JMS Selector - ret praktisk ting. Endelig JMS-abonnent:
Hvordan man håndterer det kyrilliske alfabet i sendte beskeder. I JMeter vises det som standard skævt efter korrekturlæsning. For at undgå dette og nyde det store og kraftfulde altid og overalt, skal du:
Tilføj et JVM-argument til JMeter "starteren":
-Dfile.encoding=UTF-8
Tilføj JSR223 PostProcessor til abonnent med groovy linje:
prev.setDataEncoding("UTF-8")
Send tekst
Den mest dovne mulighed. Velegnet til fejlretning af nyskrevne tests. Eller til sager, hvor du skal sende i det mindste noget lille. Vælg mulighed Beskedkilde - Textarea og placer meddelelsens brødtekst i en tekstblok:
Filoverførsel
Den mest almindelige mulighed. Velegnet til de fleste scenarier. Vælg mulighed Beskedkilde - Fra fil og angiv stien til meddelelsen i feltet Fil - Filnavn:
Overførsel af en fil til et tekstfelt
Den mest alsidige mulighed. Velegnet til de fleste scenarier + kan bruges i JMS Point-to-Point, hvor der ikke er nogen anden sendemulighed:
Sender et byte-array
Den sværeste mulighed. Velegnet til at kontrollere den ufejlbarlige nøjagtige transmission af anmodninger ned til byten, uden forvrængning, SMS og forstyrrelse. Du vil ikke være i stand til at gøre dette i standard JMeter. her Jeg fik bestemt at vide om dette.
Så jeg var nødt til at downloade kilder og ændre kode JMS abonnent.
Udskiftet i metoden extractContent(..) linje:
buffer.append(bytesMessage.getBodyLength() + " bytes received in BytesMessage");
Tilbage er blot at tilføje et par JSR223-samplere. Den første er før udgiver/abonnent-parret for at oprette en DAT-fil, der indeholder tilfældige bytes:
Jeg beskrev fire måder at sende beskeder til køer på, som jeg bruger hver dag i praksis. Jeg håber, at denne information gør dit liv lettere. I forlængelse heraf planlægger jeg at fortælle om min erfaring med at teste en central, hvor der er kø i den ene ende og en database eller filsystem i den anden.