16. Melhores Práticas ¶
16.1 Sempre use a versão mais recente do JMeter ¶
O desempenho do JMeter está sendo constantemente aprimorado, portanto, os usuários são altamente incentivados a usar a versão mais atualizada.
Certifique-se de sempre ler a lista de alterações para estar ciente das novas melhorias e componentes. Você deve evitar absolutamente o uso de versões anteriores a 3 versões anteriores à última.
16.2 Use o número correto de threads ¶
Seus recursos de hardware, bem como o design do plano de teste, afetarão o número de threads que você pode executar efetivamente com o JMeter. O número também dependerá da velocidade do seu servidor (um servidor mais rápido faz com que o JMeter trabalhe mais, pois retorna uma resposta mais rápida). Como acontece com qualquer ferramenta de teste de carga, se você não dimensionar corretamente o número de threads, enfrentará o problema de "omissão coordenada" que pode fornecer resultados errados ou imprecisos. Se você precisar de testes de carga em larga escala, considere executar várias instâncias JMeter CLI em várias máquinas usando o modo distribuído (ou não). Ao usar o modo distribuído, o arquivo de resultados é combinado no nó Controlador, se estiver usando várias instâncias autônomas, os arquivos de resultados de amostra podem ser combinados para análise subsequente. Para testar o desempenho do JMeter em uma determinada plataforma, o amostrador JavaTest pode ser usado. Ele não requer nenhum acesso à rede, portanto, pode dar uma ideia da taxa de transferência máxima alcançável.
O JMeter tem uma opção para atrasar a criação do thread até que o thread inicie a amostragem, ou seja, após qualquer atraso do grupo de threads e o tempo de aceleração para o próprio thread. Isso permite um número total muito grande de threads, desde que não haja muitos ativos simultaneamente.
16.3 Onde Colocar o Gerenciador de Cookie ¶
Consulte Construindo um Teste da Web para obter informações.
16.4 Onde Colocar o Gerenciador de Autorização ¶
Consulte Construindo um Teste da Web Avançado para obter informações.
16.5 Usando o Gravador de Script de Teste HTTP(S) ¶
Consulte Gravador de script de teste HTTP(S) para obter detalhes sobre como configurar o gravador. A coisa mais importante a fazer é filtrar todas as solicitações nas quais você não está interessado. Por exemplo, não faz sentido gravar solicitações de imagem (o JMeter pode ser instruído a baixar todas as imagens em uma página - consulte Solicitação HTTP ). Isso só vai atrapalhar seu plano de teste. Muito provavelmente, há uma extensão que todos os seus arquivos compartilham, como .jsp , .asp , .php , .html ou similares. Estes você deve " incluir " digitando " .*\.jsp " como um "Incluir Padrão".
Como alternativa, você pode excluir imagens digitando " .*\.gif " como um "Padrão de exclusão". Dependendo da sua aplicação, este pode ou não ser o melhor caminho a seguir. Você também pode ter que excluir folhas de estilo, arquivos javascript e outros arquivos incluídos. Teste suas configurações para verificar se está gravando o que deseja e, em seguida, apague e comece do zero.
O Gravador de Script de Teste HTTP(S) espera encontrar um elemento ThreadGroup com um Controlador de Gravação sob ele, onde ele gravará solicitações HTTP. Isso empacota convenientemente todas as suas amostras em um controlador, que pode receber um nome que descreve o caso de teste.
Agora, siga as etapas de um Caso de Teste. Se você não tiver casos de teste predefinidos, use o JMeter para registrar suas ações para definir seus casos de teste. Depois de concluir uma série definida de etapas, salve todo o caso de teste em um arquivo com o nome apropriado. Em seguida, limpe e inicie um novo caso de teste. Ao fazer isso, você pode gravar rapidamente um grande número de "rascunhos" de casos de teste.
Um dos recursos mais úteis do HTTP(S) Test Script Recorder é que você pode abstrair certos elementos comuns das amostras gravadas. Ao definir algumas variáveis definidas pelo usuário no nível do Plano de Teste ou nos elementos de Variáveis Definidas pelo Usuário , você pode fazer com que o JMeter substitua automaticamente os valores em suas amostras gravadas. Por exemplo, se você estiver testando um aplicativo no servidor " xxx.example.com ", você pode definir uma variável chamada " server " com o valor de " xxx.example.com " e em qualquer lugar que o valor seja encontrado em seu samples serão substituídos por " ${server} ".
Se o JMeter não registrar nenhuma amostra, verifique se o navegador realmente está usando o proxy. Se o navegador funcionar bem, mesmo que o JMeter não esteja em execução, o navegador não poderá estar usando o proxy. Alguns navegadores ignoram as configurações de proxy para localhost ou 127.0.0.1 ; tente usar o nome do host ou IP local.
O erro " unknown_ca " provavelmente significa que você está tentando gravar HTTPS e o navegador não aceitou o certificado do servidor JMeter Proxy.
16.6 Variáveis do usuário ¶
Alguns planos de teste precisam usar valores diferentes para usuários/threads diferentes. Por exemplo, você pode querer testar uma sequência que requer um login exclusivo para cada usuário. Isso é fácil de conseguir com as facilidades fornecidas pelo JMeter.
Por exemplo:
- Crie um arquivo de texto contendo os nomes de usuário e senhas, separados por vírgulas. Coloque isso no mesmo diretório que seu plano de teste.
- Adicione um elemento de configuração CSV DataSet ao plano de teste. Nomeie as variáveis USER e PASS .
- Substitua o nome de login por ${USER} e a senha por ${PASS} nos samplers apropriados
O elemento CSV Data Set lerá uma nova linha para cada thread.
16.7 Reduzindo os requisitos de recursos ¶
Algumas sugestões sobre como reduzir o uso de recursos.
- Use o modo CLI: jmeter -n -t test.jmx -l test.jtl
- Use o menor número possível de Ouvintes; se estiver usando o sinalizador -l como acima, todos eles podem ser excluídos ou desativados.
- Não use os ouvintes "Exibir árvore de resultados" ou "Exibir resultados na tabela" durante o teste de carga, use-os apenas durante a fase de script para depurar seus scripts.
- Em vez de usar muitos amostradores semelhantes, use o mesmo amostrador em um loop e use variáveis (Conjunto de dados CSV) para variar a amostra. [O Include Controller não ajuda aqui, pois adiciona todos os elementos de teste do arquivo ao plano de teste.]
- Não use o modo funcional
- Use a saída CSV em vez de XML
- Salve apenas os dados que você precisa
- Use o mínimo de asserções possível
- Use a linguagem de script com melhor desempenho (consulte a seção JSR223)
Se seu teste precisar de grandes quantidades de dados - principalmente se precisar ser randomizado - crie os dados de teste em um arquivo que possa ser lido com o conjunto de dados CSV. Isso evita o desperdício de recursos em tempo de execução.
16.8 Servidor BeanShell ¶
O interpretador BeanShell possui um recurso muito útil - ele pode atuar como um servidor, acessível por telnet ou http.
Se você deseja usar o servidor, defina o seguinte em jmeter.properties :
beanshell.server.port=9000 beanshell.server.file=../extras/startup.bsh
No exemplo acima, o servidor será iniciado e escutará nas portas 9000 e 9001 . A porta 9000 será usada para acesso http. A porta 9001 será usada para acesso telnet. O arquivo startup.bsh será processado pelo servidor e pode ser usado para definir várias funções e configurar variáveis. O arquivo de inicialização define métodos para configurar e imprimir o JMeter e as propriedades do sistema. Isto é o que você deve ver no console do JMeter:
Script de inicialização em execução Script de inicialização concluído Httpd iniciado na porta: 9000 Sessão iniciada na porta: 9001
Existe um script de exemplo ( extras/remote.bsh ) que você pode usar para testar o servidor. [Dê uma olhada para ver como funciona.]
Ao iniciá-lo no diretório bin
JMeter (ajuste os caminhos conforme necessário se estiver executando de outro lugar), a saída deve ser semelhante a:
$ java -jar ../lib/bshclient.jar localhost 9000 ../extras/remote.bsh Conectando-se ao servidor BSH no localhost:9000 Lendo respostas do servidor… BeanShell 2.0b5 - por Pat Niemeyer (pat@pat.net) bsh % remote.bsh iniciando user.home = C:\Documents and Settings\Usuário user.dir = D:\eclipseworkspaces\main\JMeter_trunk\bin Configurando a propriedade 'EXEMPLO' para '0'. Configurando a propriedade 'EXEMPLO' para '1'. Configurando a propriedade 'EXEMPLO' para '2'. Configurando a propriedade 'EXEMPLO' para '3'. Configurando a propriedade 'EXEMPLO' para '4'. Configurando a propriedade 'EXEMPLO' para '5'. Configurando a propriedade 'EXEMPLO' para '6'. Configurando a propriedade 'EXEMPLO' para '7'. Configurando a propriedade 'EXEMPLO' para '8'. Configurando a propriedade 'EXEMPLO' para '9'. EXEMPLO = 9 remote.bsh terminou bsh % … desconectado do servidor.
Como exemplo prático, suponha que você tenha um teste JMeter de longa duração em execução no modo CLI e queira variar a taxa de transferência em vários momentos durante o teste. O plano de teste inclui um Constant Throughput Timer que é definido em termos de uma propriedade, por exemplo ${__P(throughput)} . Os seguintes comandos do BeanShell podem ser usados para alterar o teste:
printprop("taxa");
curr = Integer.decode(args[0]); // Valor inicial
inc = Integer.decode(args[1]); // Incrementar
end = Integer.decode(args[2]); //Valor final
segundos = Integer.decode(args[3]); // Espera entre as mudanças
while(curr <= fim) {
setprop("taxa de transferência",curr.toString()); // Precisa ser uma string aqui
Thread.sleep(s*1000);
curr += inc;
}
printprop("taxa");
O script pode ser armazenado em um arquivo ( throughput.bsh , digamos) e enviado ao servidor usando bshclient.jar . Por exemplo:
java -jar ../lib/bshclient.jar localhost 9000 throughput.bsh 70 5 100 60
16.9 Script do BeanShell ¶
16.9.1 Visão geral ¶
Cada elemento de teste do BeanShell tem sua própria cópia do interpretador (para cada thread). Se o elemento de teste for chamado repetidamente, por exemplo, dentro de um loop, o interpretador será retido entre as invocações, a menos que a opção " Redefinir bsh.Interpreter antes de cada chamada " seja selecionada.
Alguns testes de longa duração podem fazer com que o interpretador use muita memória; se este for o caso, tente usar a opção de redefinição.
Você pode testar scripts do BeanShell fora do JMeter usando o interpretador de linha de comando:
$ java -cp bsh-xxx.jar[;outros jars conforme necessário] bsh.Interpreter file.bsh [parâmetros]ou
$ java -cp bsh-xxx.jar bsh.Interpreter
bsh% source("arquivo.bsh");
bsh% exit(); // ou use a tecla EOF (por exemplo, ^Z ou ^D)
16.9.2 Compartilhando Variáveis ¶
As variáveis podem ser definidas em scripts de inicialização (inicialização). Eles serão retidos nas invocações do elemento de teste, a menos que a opção de redefinição seja usada.
Scripts também podem acessar variáveis JMeter usando os métodos get() e put() da variável " vars ", por exemplo:
vars.get("HOST");
vars.put("MSG","Sucesso");
Os métodos get() e put() suportam apenas variáveis com valores String, mas também existem métodos getObject() e putObject() que podem ser usados para objetos arbitrários. As variáveis JMeter são locais para um encadeamento, mas podem ser usadas por todos os elementos de teste (não apenas pelo Beanshell).
Se você precisar compartilhar variáveis entre threads, as propriedades do JMeter podem ser usadas:
importar org.apache.jmeter.util.JMeterUtils;
Valor da string = JMeterUtils.getPropDefault("nome","");
JMeterUtils.setProperty("nome", "valor");
Os arquivos .bshrc de amostra contêm definições de amostra dos métodos getprop() e setprop() .
Outro método possível de compartilhar variáveis é usar o namespace compartilhado " bsh.shared ". Por exemplo:
if (bsh.shared.myObj == void){
// ainda não definido, então crie-o:
meuObj = new QualquerObjeto();
}
bsh.shared.myObj.process();
Em vez de criar o objeto no elemento de teste, ele pode ser criado no arquivo de inicialização definido pela propriedade do JMeter " beanshell.init.file ". Isso é processado apenas uma vez.
16.10 Desenvolvendo funções de script em Groovy ou Jexl3 etc. ¶
É muito difícil escrever e testar scripts como funções. No entanto, o JMeter possui os samplers JSR223 que podem ser usados com qualquer idioma que o suporte. Aconselhamos o uso do Apache Groovy ou qualquer linguagem que suporte a interface Compilável do JSR223.
Crie um Plano de Teste simples contendo o Amostrador JSR223 e o Ouvinte de Visualização em Árvore. Codifique o script no painel de script do amostrador e teste-o executando o teste. Se houver algum erro, ele aparecerá na visualização em árvore e no arquivo jmeter.log . Além disso, o resultado da execução do script aparecerá como resposta.
Uma vez que o script esteja funcionando corretamente, ele pode ser armazenado como uma variável no Plano de Testes. A variável de script pode então ser usada para criar a chamada de função. Por exemplo, suponha que um script Groovy seja armazenado na variável RANDOM_NAME . A chamada de função pode ser codificada como ${__groovy(${RANDOM_NAME})} . Não há necessidade de escapar nenhuma vírgula no script, porque a chamada da função é analisada antes que o valor da variável seja interpolado.
16.11 Testes de parametrização ¶
Muitas vezes é útil poder executar novamente o mesmo teste com configurações diferentes. Por exemplo, alterando o número de encadeamentos ou loops ou alterando um nome de host.
Uma maneira de fazer isso é definir um conjunto de variáveis no Plano de Teste e, em seguida, usar essas variáveis nos elementos de teste. Por exemplo, pode-se definir a variável LOOPS=10 , e referir-se a ela no Thread Group como ${LOOPS} . Para executar o teste com 20 loops, basta alterar o valor da variável LOOPS no Plano de Testes.
Isso rapidamente se torna tedioso se você deseja executar muitos testes no modo CLI. Uma solução para isso é definir a variável Plano de Teste em termos de uma propriedade, por exemplo LOOPS=${__P(loops,10)} . Isso usa o valor da propriedade " loops ", assumindo o valor padrão 10 se a propriedade não for encontrada. A propriedade " loops " pode então ser definida na linha de comando do JMeter:
jmeter … -Jloops=12 …Se houver muitas propriedades que precisam ser alteradas juntas, uma maneira de conseguir isso é usar um conjunto de arquivos de propriedades. O arquivo de propriedades apropriado pode ser passado para o JMeter usando a opção de linha de comando -q .
16.12 Elementos JSR223 ¶
Para testes de carga intensivos, a linguagem de script recomendada é aquela cujo ScriptingEngine implementa a interface Compilable . O mecanismo de script Groovy implementa Compilable . No entanto, nem o Beanshell nem o Javascript o fazem na data de lançamento do JMeter 3.1, portanto, é recomendável evitá-los para testes de carga intensivos.
vars.get("varName")
Você também pode passá-los como Parâmetros para o script e usá-los dessa maneira.
16.13 Compartilhando variáveis entre threads e grupos de threads ¶
As variáveis são locais para um encadeamento; uma variável definida em um thread não pode ser lida em outro. Isso é por design. Para variáveis que podem ser determinadas antes do início de um teste, consulte Testes de Parametrização (acima). Se o valor não for conhecido até o início do teste, existem várias opções:
- Armazene a variável como uma propriedade - as propriedades são globais para a instância do JMeter
- Escreva variáveis em um arquivo e leia-as novamente.
- Use o namespace bsh.shared - veja acima
- Escreva suas próprias classes Java
16.14 Gerenciando propriedades ¶
Quando você precisar modificar as propriedades do jmeter, certifique-se de não modificar o arquivo
jmeter.properties , em vez disso copie a propriedade de jmeter.properties e modifique seu valor no arquivo user.properties .
Isso facilitará a migração para a próxima versão do JMeter.
Observe que na documentação jmeter.properties é frequentemente mencionado, mas deve ser entendido como "Copie de jmeter.properties para user.properties a propriedade que deseja modificar e faça isso no último arquivo".
16.15 Elementos obsoletos ¶
É aconselhável não usar elementos obsoletos (marcados como tal na lista de alterações e na referência do componente ) e migrar para novos elementos recomendados, se disponíveis, ou nova maneira de fazer a mesma coisa.
Elementos obsoletos são removidos do menu na versão N, mas podem ser ativados para migração modificando a propriedade not_in_menu no arquivo user.properties e removendo o nome completo da classe do elemento de lá.