Hola Habr!
Esta es una secuela de mi
publicación anterior , en la que hablaré sobre las opciones para colocar mensajes en colas usando JMeter.
Hacemos un bus de datos para una gran empresa federal. Varios formatos de consulta, conversiones, enrutamiento intrincado. Para las pruebas, debe enviar muchos mensajes en la cola. Manualmente, un dolor que no todos los ingenieros manuales enfrentarán.
Introduccion
Aunque tuve que soportar este dolor al principio. Todo comenzó con RFHUtil. Potente, pero incómodo y aterrador:
Bueno, ya sabes Rus.
Indispensable en algunos casos, pero establemente cayendo en caso de uso activo.
Pruebas convenientes con él es imposible.
Con JMeter, las cosas se pusieron más fáciles. Después de la primera etapa de masterización y de acostumbrarse, llegó la esperanza de una prueba feliz.
Utilizo activamente los muestreadores JMS Publisher y JMS Subscriber. A diferencia de JMS Point-to-Point, esta pareja parecía más conveniente para trabajar. Por ejemplo, puede especificar una variable para el suscriptor en el selector JMS, para punto a punto, no (o este método no es demasiado obvio).
Preparación de muestra
JMS Publisher
- Configuración: cada muestra. Apache recomienda usar esta opción si las colas / temas se especifican a través de variables.
- Caducidad (ms) = 120000. En caso de falla, las solicitudes de prueba desaparecerán de la cola después de 2 minutos.
- ¿Usar el modo de entrega no persistente? - cierto. IBM afirma que el modo persistente proporciona una persistencia confiable de los mensajes en caso de una falla repentina. Y compartir más rápido en modo no persistente. Para fines de prueba, la velocidad es más importante.
En cada editor, configuro la propiedad jms que el suscriptor usará en el selector JMS. Para cada envío, se genera un valor aleatorio en el elemento del plan de prueba Parámetros de usuario:
Por lo tanto, puede estar seguro de que se ha leído el mensaje correcto.
El "espacio en blanco" final del editor JMS preconfigurado:
Suscriptor Jms
- Configuración: cada muestra. Bueno, entiendes el punto.
- Tiempo de espera (ms) = 100000. Si la solicitud no entra en la cola después de 100 segundos de espera, entonces algo salió mal.
- ¿Parar entre muestra? - cierto.
JMS Selector es algo bastante útil. Resumen del suscriptor de JMS:
Cómo lidiar con el alfabeto cirílico en los mensajes transmitidos. En JMeter, por defecto, después de la resta, se muestra torcidamente. Para evitar esto y disfrutar de lo grandioso y poderoso siempre y en todas partes, necesita:
- Agregue el argumento JVM al "lanzador" de JMeter:
-Dfile.encoding=UTF-8
- Agregue JSR223 PostProcessor al suscriptor con una línea en groovy:
prev.setDataEncoding("UTF-8")
Transferencia de texto
La opción más perezosa. Adecuado para depurar pruebas recién escritas. O para casos en los que necesita enviar al menos algo pequeño. Seleccione la opción
Origen del mensaje - Área de texto y coloque el cuerpo del mensaje en un bloque de texto:
Transferencia de archivos
La opción más común. Apto para la mayoría de los escenarios. Seleccione la opción
Origen del mensaje - Desde el archivo y especifique la ruta al mensaje en el campo
Archivo - Nombre del archivo:
Transferir archivo a campo de texto
La opción más versátil. Adecuado para la mayoría de los escenarios + se puede utilizar en JMS Point-to-Point, en el que no hay una segunda opción de envío:
Transferencia de matriz de bytes
La opción más difícil. Adecuado para verificar la transferencia infaliblemente precisa de solicitudes al byte, sin distorsión, SMS y perturbación. No puedo hacer esto en el JMeter predeterminado,
aquí definitivamente me lo contaron.
Por lo tanto, tuve que descargar las
fuentes y modificar
el código de suscriptor JMS.
Reemplazó la línea en el
extractContent(..) :
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); }
y reconstruido JMeter.
Queda por agregar un par de JSR223 Sampler. El primero es antes del par Editor / Suscriptor para crear un archivo .dat que contiene 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:\\temp\\randomBytes.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 segundo, al final del guión, elimina el archivo:
import java.io.File; File RESULT_FILE = new File(vars.get("PATH_TO_BYTES")); RESULT_FILE.delete();
Y no olvide agregar la ruta al archivo desde Publisher:
Y también una comprobación en la Afirmación JSR223 para el Suscriptor: compare los bytes de origen con los que vienen en la cola del receptor:
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
Describió cuatro formas de enviar mensajes en una cola, que uso en la práctica todos los días. Espero que esta información te haga la vida más fácil. En la secuela, planeo hablar sobre mi experiencia en probar intercambios, donde en un extremo está la cola, y en el otro está la base de datos o el sistema de archivos.
Cuida tu tiempo. Y gracias por mirar.