Hola, Habr! Aquesta és una seqüela de la meva , en què parlaré de les opcions per col·locar missatges a les cues mitjançant JMeter.
Estem fent un bus de dades per a una gran empresa federal. Diversos formats de sol·licitud, transformacions, encaminament complex. Per provar, heu d'enviar molts missatges a la cua. Manualment és un dolor que no tots els quiropràctics poden manejar.
Introducció
Tot i que al principi vaig haver de suportar aquest dolor. Tot va començar amb RFHUtil. Potent, però incòmode i espantós: Bé, ja coneixes Rus.
Imprescindible en alguns casos, però en declivi constant en cas d'ús actiu.
Les proves convenients són impossibles amb això.
Amb JMeter tot s'ha tornat més fàcil. Després de la primera etapa de dominar i acostumar-s'hi, va començar a sorgir l'esperança per a proves feliços.
Utilitzo activament els mostradors JMS Publisher i JMS Subscriber. A diferència de JMS Point-to-Point, aquest parell semblava més còmode d'utilitzar. Per exemple, amb Subscriber a JMS Selector podeu especificar una variable, però amb Point-to-Point no (o aquest mètode no és molt obvi).
Preparació de mostres
JMS Editor
- Configuració: cada mostra. Apache utilitzeu aquesta opció si s'especifiquen cues/temes mitjançant variables.
- Caducitat (ms) = 120000. En cas d'error, les sol·licituds de prova desapareixeran de la cua al cap de 2 minuts.
- Utilitzeu el mode de lliurament no persistent? - veritat. IBM aquest mode persistent garanteix una preservació fiable dels missatges transmesos en cas d'una fallada sobtada. I intercanvi més ràpid en mode no persistent. A efectes de prova, la velocitat és més important.
A cada editor he definit una propietat jms que el subscriptor utilitzarà al selector JMS. Per a cada enviament, es genera un valor aleatori a l'element del pla de prova de Paràmetres d'usuari:
D'aquesta manera, podeu estar segur que s'ha llegit el missatge correcte.
El "buig" final d'un editor JMS preconfigurat:
Subscriptor JMS
- Configuració: cada mostra. Bé, ho entens.
- Temps d'espera (ms) = 100000. Si la sol·licitud no arriba a la cua després de 100 segons d'espera, hi ha hagut un error.
- Parar entre mostres? - veritat.
JMS Selector - força convenient . Subscriptor final de JMS:
Com tractar l'alfabet ciríl·lic en els missatges transmesos. A JMeter, de manera predeterminada, després de la correcció, es mostra de manera torcida. Per evitar-ho i gaudir del gran i poderós sempre i a tot arreu, cal:
- Afegiu un argument JVM al "llançador" de JMeter:
-Dfile.encoding=UTF-8 - Afegeix un postprocessador JSR223 al subscriptor amb una línia groovy:
prev.setDataEncoding("UTF-8")
Envia text
L'opció més mandrosa. Adequat per depurar proves acabades de redactar. O per als casos en què necessiteu enviar almenys alguna cosa petita. Seleccioneu l'opció Font del missatge - Àrea de text i col·loqueu el cos del missatge en un bloc de text:
Transferència de fitxers
L'opció més habitual. Apte per a la majoria d'escenaris. Seleccioneu l'opció Font del missatge: del fitxer i indiqueu el camí al missatge al camp Fitxer - Nom del fitxer:
Transferència d'un fitxer a un camp de text
L'opció més versàtil. Adequat per a la majoria d'escenaris + es pot utilitzar a JMS punt a punt on no hi ha una segona opció d'enviament:
Passant una matriu de bytes
L'opció més difícil. Adequat per comprovar la transmissió infal·liblement precisa de peticions fins al byte, sense distorsió, SMS i pertorbacions. No podreu fer-ho al JMeter predeterminat. Definitivament em van parlar d'això.
Així que vaig haver de descarregar i modificar Subscriptor JMS.
Substituït en el mètode extractContent(..) línia:
buffer.append(bytesMessage.getBodyLength() + " bytes received in BytesMessage");a:
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 va reconstruir JMeter.
Només queda afegir un parell de Samplers JSR223. El primer és abans de la parella Editor/Subscriptor per crear un fitxer DAT que conté bytes aleatoris:
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");
}El segon, al final de l'script, elimina el fitxer:
import java.io.File;
File RESULT_FILE = new File(vars.get("PATH_TO_BYTES"));
RESULT_FILE.delete();I no us oblideu d'afegir el camí al fitxer a Publisher:
I també una comprovació a l'asserció JSR223 per al subscriptor: compareu els bytes d'origen amb els que arriben a la cua del destinatari:
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;
}Conclusió
Vaig descriure quatre maneres d'enviar missatges a les cues, que utilitzo cada dia a la pràctica. Espero que aquesta informació et faci la vida més fàcil. A continuació, penso parlar de la meva experiència de provar un intercanvi on hi ha una cua a un extrem i una base de dades o un sistema de fitxers a l'altre.
Estalvieu el vostre temps. I gràcies per la vostra atenció.
Font: www.habr.com