Olá, Habr! Esta é a sequência da minha , na qual falarei sobre opções de publicação de mensagens em filas usando JMeter.
Estamos criando um barramento de dados para uma grande empresa federal. Diferentes formatos de solicitações, transformações, roteamento complexo. Para testes, é necessário enviar muitas mensagens para as filas. Fazer isso manualmente é um sofrimento que nem todos os testadores aguentam.
Introdução
Embora tenhamos que lidar com esse sofrimento no início. Tudo começou com RFHUtil. Poderoso, mas inconveniente e assustador: Vocês sabem como é o Rus.
Indispensável em alguns casos, mas constantemente falhando sob uso ativo.
Testes eficazes com ele são impossíveis.
Com o JMeter ficou tudo mais fácil. Após a fase inicial de aprendizado e adaptação, surgiu a esperança de testes felizes.
Utilizo ativamente os amostradores JMS Publisher e JMS Subscriber. Ao contrário do JMS Point-to-Point, esta dupla pareceu mais conveniente de trabalhar. Por exemplo, no Subscriber, o JMS Selector permite especificar uma variável, já no Point-to-Point — não (ou esse método não é muito óbvio).
Preparação dos amostradores
JMS Publisher
- Configuração — Cada Amostra. Apache usar esta opção se as filas/tópicos forem definidos por variáveis.
- Expiração (ms) = 120000. Em caso de falha, as solicitações de teste desaparecerão da fila após 2 minutos.
- Usar modo de entrega não persistente? — verdadeiro. A IBM , que o modo persistente garante a salvaguarda confiável das mensagens transmitidas em caso de falha repentina. E a troca mais rápida no modo não persistente. Para fins de teste, a velocidade é mais importante.
Em cada Publisher, defino uma propriedade JMS que o Subscriber usará no JMS Selector. Para cada envio, um valor aleatório é gerado no elemento do plano de teste User Parameters:
Assim, pode-se ter certeza de que a mensagem correta foi lida.
O modelo final do JMS Publisher pré-configurado:
JMS Subscriber
- Configuração — Cada Amostra. Você entendeu.
- Timeout (ms) = 100000. Se a solicitação não chega à fila após 100 segundos de espera, significa que algo deu errado.
- Parar entre amostras? — verdadeiro.
JMS Selector — uma ferramenta bastante conveniente Como lidar com a escrita em cirílico nas mensagens transmitidas. No JMeter, por padrão, após a leitura, ela é exibida de forma estranha. Para evitar isso e desfrutar do grande e poderoso sempre e em qualquer lugar, é necessário:
Adicionar ao "launcher" do JMeter o argumento JVM:
- -Dfile.encoding=UTF-8
Adicionar um JSR223 PostProcessor no Subscriber com a linha em groovy: - prev.setDataEncoding("UTF-8")
prev.setDataEncoding("UTF-8")
Transmissão de texto
A opção mais preguiçosa. Adequada para depurar testes recém-escritos. Ou para casos em que é necessário enviar algo pequeno. Escolha a opção Fonte da mensagem — Área de texto e coloque o corpo da mensagem no bloco de texto:
Transmissão de arquivo
A opção mais comum. Adequada para a maioria dos cenários. Escolha a opção Fonte da mensagem — A partir de arquivo e indique o caminho para a mensagem no campo Arquivo — Nome do arquivo:
Transmissão de arquivo no campo de texto
A opção mais universal. Adequada para a maioria dos cenários + pode ser usada em JMS Point-to-Point, onde não há uma segunda opção de envio:
Transmissão de array de bytes
A opção mais complicada. Adequada para verificar a transmissão absolutamente precisa de requisições até o byte, sem distorções, SMS e perturbações. Isso não pode ser feito no JMeter padrão, me disseram isso com certeza.
Por isso, tive que baixar e modificar JMS Subscriber.
Substituí na metodologia extractContent(..) a linha:
buffer.append(bytesMessage.getBodyLength() + " bytes recebidos em BytesMessage");por:
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 recompus JMeter.
Sobraram apenas alguns JSR223 Samplers para adicionar. O primeiro — antes do par Publisher/Subscriber para criar um arquivo DAT contendo bytes aleatórios:
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("arquivo não encontrado");
}O segundo — no final do cenário, exclui o arquivo:
import java.io.File;
File RESULT_FILE = new File(vars.get("PATH_TO_BYTES"));
RESULT_FILE.delete();E não se esqueça de adicionar o caminho do arquivo ao Publisher:
E também uma verificação no JSR223 Assertion para o Subscriber — comparar os bytes originais com os que chegam na fila do 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("Comparação falhou");
SampleResult.setResponseData("Os bytes mudaram","UTF-8");
IsSuccess=false;
}Conclusão
Descrevi quatro maneiras de enviar mensagens em uma fila que utilizo diariamente na prática. Espero que essas informações tornem sua vida mais fácil. No futuro, pretendo compartilhar minha experiência de teste de troca, onde de um lado está a fila e do outro, um banco de dados ou um sistema de arquivos.
Cuide do seu tempo. E obrigado pela atenção.
Fonte: habr.com
