Ola, Habr! Esta é unha secuela da miña , no que falarei das opcións para colocar mensaxes en filas mediante JMeter.
Estamos a facer un bus de datos para unha gran empresa federal. Varios formatos de solicitude, transformacións, enrutamento complicado. Para probar, cómpre enviar moitas mensaxes á cola. Manualmente é unha dor que non todos os quiroprácticos poden manexar.
Introdución
Aínda que tiven que aguantar esta dor nun primeiro momento. Todo comezou con RFHUtil. Poderoso, pero torpe e asustado: ben, xa coñeces a Rus.
Imprescindible nalgúns casos, pero en diminución constante no caso de uso activo.
As probas convenientes son imposibles con el.
Con JMeter todo se fixo máis doado. Despois da primeira etapa de masterización e acostumación, comezou a aflorar a esperanza de probas felices.
Uso activamente os mostradores de JMS Publisher e JMS Subscriber. A diferenza de JMS Point-to-Point, este par parecía máis cómodo de usar. Por exemplo, con Subscriber en JMS Selector podes especificar unha variable, pero con Point-to-Point non (ou este método non é moi obvio).
Preparación de mostradores
JMS Editor
- Configuración: cada mostra. Apache use esta opción se as colas/temas se especifican mediante variables.
- Caducidade (ms) = 120000. En caso de falla, as solicitudes de proba desaparecerán da cola despois de 2 minutos.
- Usa o modo de entrega non persistente? - verdade. IBM ese modo persistente garante a conservación fiable das mensaxes transmitidas en caso de fallo repentino. E intercambio máis rápido en modo non persistente. Para fins de proba, a velocidade é máis importante.
En cada editor establezo unha propiedade jms que o subscritor utilizará no selector JMS. Para cada envío, xérase un valor aleatorio no elemento do plan de proba de parámetros de usuario:
Deste xeito, podes estar seguro de que se le a mensaxe correcta.
O "blank" final dun editor JMS preconfigurado:
Abonado JMS
- Configuración: cada mostra. Ben, entendes.
- Tempo de espera (ms) = 100000. Se a solicitude non chega á cola despois de 100 segundos de espera, algo saíu mal.
- Parar entre mostras? - verdade.
JMS Selector - bastante cómodo . Abonado final de JMS:
Como tratar co alfabeto cirílico nas mensaxes transmitidas. En JMeter, por defecto, despois da corrección, móstrase de forma torcida. Para evitar isto e gozar do grande e poderoso sempre e en todas partes, cómpre:
- Engade un argumento JVM ao "lanzador" de JMeter:
-Dfile.encoding=UTF-8 - Engade o postprocesador JSR223 ao abonado cunha liña groovy:
prev.setDataEncoding("UTF-8")
Enviar texto
A opción máis preguiceira. Axeitado para depurar probas recentemente escritas. Ou para os casos nos que necesites enviar polo menos algo pequeno. Seleccione opción Orixe da mensaxe - Textarea e coloca o corpo da mensaxe nun bloque de texto:
Transferencia de ficheiros
A opción máis común. Adecuado para a maioría dos escenarios. Seleccione opción Orixe da mensaxe: desde o ficheiro e indique no campo o camiño da mensaxe Ficheiro - Nome do ficheiro:
Transferir un ficheiro a un campo de texto
A opción máis versátil. Adecuado para a maioría dos escenarios + pódese usar en JMS Point-to-Point onde non hai unha segunda opción de envío:
Pasando unha matriz de bytes
A opción máis difícil. Axeitada para comprobar a transmisión infaliblemente precisa de solicitudes ata o byte, sen distorsións, SMS e perturbacións. Non poderás facelo no JMeter predeterminado. Definitivamente faláronme disto.
Entón tiven que descargar e modificar Abonado JMS.
Substituído no método extractContent(..) liña:
buffer.append(bytesMessage.getBodyLength() + " bytes received in BytesMessage");en:
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);
}e reconstruíu JMeter.
Todo o que queda é engadir un par de mostradores JSR223. O primeiro é antes do par Editor/Subscritor para crear un ficheiro DAT que contén bytes aleatorios:
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");
}O segundo, ao final do script, elimina o ficheiro:
import java.io.File;
File RESULT_FILE = new File(vars.get("PATH_TO_BYTES"));
RESULT_FILE.delete();E non esquezas engadir o camiño ao ficheiro en Publisher:
E tamén unha comprobación na Aserción JSR223 para o abonado: compare os bytes de orixe cos que chegan á cola do destinatario:
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ón
Describín catro formas de enviar mensaxes ás filas, que uso todos os días na práctica. Espero que esta información che facilite a vida. A continuación, penso falar da miña experiencia de probar un intercambio onde hai unha cola nun extremo e unha base de datos ou sistema de ficheiros no outro.
Aforra o teu tempo. E grazas pola túa atención.
Fonte: www.habr.com