13. Teste Remoto

13.1 Configurando SSL ¶

A configuração mais simples é usar um par de chave/certificado para todos os servidores e clientes JMeter que você deseja conectar. O JMeter vem com um script para gerar um keystore que contém uma chave (e seu certificado correspondente) chamado rmi . O script está localizado no diretório bin e está disponível para sistemas Windows (chamados bin/create-rmi-keystore.bat ) e sistemas do tipo Unix (chamados bin/create-rmi-keystore.sh ). Ele irá gerar um par de chaves, que é válido por sete dias, com uma senha padrão de valor ' changeit '. É aconselhável chamá-lo de dentro do diretório bin .

Quando você executar o script, ele fará algumas perguntas sobre alguns nomes que serão incorporados ao certificado. Você pode digitar o que quiser, desde que a ferramenta keystore aceite. Esse valor deve corresponder à propriedade server.rmi.ssl.keystore.alias , cujo padrão é rmi . Uma sessão de amostra para criar o keystore é mostrada abaixo.

$ cd jmeter/bin
$ ./create-rmi-keystore.sh
Qual é o seu primeiro e último nome?
  [Desconhecido]: rmi
Qual o nome da sua unidade organizacional?
  [Desconhecido]: Nome da minha unidade
Qual é o nome da sua organização?
  [Desconhecido]: nome da minha organização
Qual o nome da sua cidade ou localidade?
  [Desconhecido]: Sua cidade
Qual é o nome do seu Estado ou Província?
  [Desconhecido]: Seu Estado
Qual é o código de país de duas letras para esta unidade?
  [Desconhecido]: XY
CN=rmi, OU=nome da minha unidade, O=nome da minha organização, L=sua cidade, ST=seu estado, C=XY está correto?
  [não]: sim

Copie o rmi_keystore.jks gerado para a pasta jmeter/bin ou faça referência a ele na propriedade 'server.rmi.ssl.keystore.file'

As configurações padrão para RMI devem funcionar com esta configuração. Copie o arquivo bin/rmi_keystore.jks para cada servidor e cliente JMeter que você deseja usar para sua configuração de teste distribuído.

13.2 Fazendo manualmente ¶

Em alguns casos, o script jmeter-server pode não funcionar para você (se você estiver usando uma plataforma de SO não prevista pelos desenvolvedores do JMeter). Aqui está como iniciar os servidores JMeter (etapa 1 acima) com um processo mais manual:

Etapa 1a: Iniciar o Registro RMI

Desde o JMeter 2.3.1, o registro RMI é iniciado pelo servidor JMeter, portanto, esta seção não se aplica ao caso normal. Para reverter para o comportamento anterior, defina a propriedade JMeter server.rmi.create=false nos sistemas host do servidor e siga as instruções abaixo.

O JMeter usa Remote Method Invocation (RMI) como mecanismo de comunicação remota. Portanto, você precisa executar o aplicativo RMI Registry (que é chamado de " rmiregistry ") que vem com o JDK e está localizado no diretório " bin ". Antes de executar rmiregistry , certifique-se de que os seguintes jars estejam no classpath do seu sistema:

• JMETER_HOME/lib/ext/ApacheJMeter_core.jar
• JMETER_HOME/lib/jorphan.jar
• JMETER_HOME/lib/logkit-2.0.jar

Etapa 1b: Iniciar o servidor JMeter

Quando o aplicativo RMI Registry estiver em execução, inicie o JMeter Server. Use a opção " -s " com o script de inicialização do jmeter (" jmeter -s ").

Os passos 2 e 3 permanecem os mesmos.

13.3 Dicas ¶

O JMeter/RMI requer uma conexão do cliente com o servidor. Isso usará a porta que você escolheu, padrão 1099 .
O JMeter/RMI também requer uma conexão reversa para retornar resultados de amostra do servidor para o cliente.
Eles usarão portas com números altos.
Essas portas podem ser controladas pela propriedade jmeter chamada client.rmi.localport em jmeter.properties .
Se for diferente de zero, será usado como base para números de porta locais para o mecanismo cliente. No momento o JMeter abrirá até três portas começando com a porta definida em client.rmi.localport. Se houver firewalls ou outros filtros de rede entre o cliente e o servidor JMeter, você precisará certificar-se de que eles estejam configurados para permitir as conexões. Se necessário, use um software de monitoramento para mostrar qual tráfego está sendo gerado.

Se você estiver executando o Suse Linux, essas dicas podem ajudar. A instalação padrão pode habilitar o firewall. Nesse caso, o teste remoto não funcionará corretamente. As dicas a seguir foram contribuídas por Sergey Ten.

Se você vir conexões recusadas, ative a depuração passando as opções a seguir.

rmiregistry -J-Dsun.rmi.log.debug=true \
     -J-Dsun.rmi.server.exceptionTrace=true \
     -J-Dsun.rmi.loader.logLevel=verbose \
     -J-Dsun.rmi.dgc.logLevel=verbose \
     -J-Dsun.rmi.transport.logLevel=verbose \
     -J-Dsun.rmi.transport.tcp.logLevel=verbose \

Desde o JMeter 2.3.1, o registro RMI é iniciado pelo servidor; no entanto, as opções ainda podem ser transmitidas a partir da linha de comando do JMeter. Por exemplo: " jmeter -s -Dsun.rmi.loader.logLevel=verbose " (ou seja, omita os prefixos -J ). Alternativamente, as propriedades podem ser definidas no arquivo system.properties .

A solução para o problema é remover os loopbacks 127.0.0.1 e 127.0.0.2 de /etc/hosts . O que acontece é que o servidor jmeter não pode se conectar ao rmiregistry se o loopback 127.0.0.2 não estiver disponível. Use as configurações a seguir para corrigir o problema.

Substituir

`dirname $0`/jmeter -s "$@"

Com

HOST="-Djava.rmi.server.hostname=[nome_do_computador][domínio_do_computador] \
      -Djava.security.policy=`dirname $0`/[policy_file]" \
`dirname $0`/jmeter $HOST -s "$@"

Crie também um arquivo de política e adicione a linha [computer_name][computer_domain] ao /etc/hosts .

Para melhor suportar o encapsulamento SSH dos canais de comunicação RMI usados ​​em testes remotos, desde o JMeter 2.6:

• uma nova propriedade " client.rmi.localport " pode ser configurada para controlar a porta RMI usada pelo RemoteSampleListenerImpl
• Para suportar o encapsulamento de tráfego RMI em um túnel SSH como o terminal remoto usando uma porta na máquina local, a interface de loopback agora pode ser usada se tiver sido especificada diretamente usando o parâmetro Java System Property " java.rmi.server.hostname " .

13.4 Usando uma porta diferente ¶

Por padrão, o JMeter usa a porta RMI padrão 1099 . É possível mudar isso. Para que isso funcione com sucesso, todos os itens a seguir precisam estar de acordo:

• No servidor, inicie o rmiregistry usando o novo número da porta
• No servidor, inicie o JMeter com a propriedade server_port definida
• No cliente, atualize a propriedade remote_hosts para incluir as novas configurações de host:port remoto

Desde o JMeter 2.1.1, os scripts jmeter-server fornecem suporte para alterar a porta. Por exemplo, suponha que você queira usar a porta 1664 (talvez 1099 já seja usada).

C:\JMETER> SET SERVER_PORT=1664
C:\JMETER> JMETER-SERVER [outras opções]

$ SERVER_PORT=1664 jmeter-server [outras opções]

Em ambos os casos, o script inicia o rmiregistry na porta especificada, e então inicia o JMeter no modo servidor, tendo definido a propriedade " server_port ".

A porta escolhida será registrada no arquivo jmeter.log do servidor (o rmiregistry não cria um arquivo de log).

13.5 Usando um remetente de amostra diferente ¶

Os listeners no plano de teste enviam seus resultados de volta para o cliente JMeter que grava os resultados nos arquivos especificados Por padrão, as amostras são enviadas de volta de forma síncrona à medida que são geradas. Isso pode afetar o rendimento máximo do teste do servidor; o resultado da amostra deve ser enviado de volta antes que o encadeamento possa continuar. Existem algumas propriedades do JMeter que podem ser configuradas para alterar esse comportamento.

modo

modo de envio de amostra - o padrão é StrippedBatch desde 2.9. Isso deve ser definido no nó cliente.

Padrão

enviar amostras de forma síncrona assim que forem geradas

Aguarde

mantenha as amostras em uma matriz até o final de uma corrida. Isso pode usar muita memória no servidor e é desencorajado.

DiskStore

armazene amostras em um arquivo de disco (em java.io.temp ) até o final de uma execução. O arquivo de dados serializado é excluído na saída da JVM.

StrippedDiskStore

remova responseData de amostras bem-sucedidas e use o remetente DiskStore para enviá-las.

Lote

enviar amostras salvas quando a contagem ( num_sample_threshold ) ou o tempo ( time_threshold ) exceder um limite, no qual as amostras são enviadas de forma síncrona. Os limites podem ser configurados no servidor usando as seguintes propriedades:

num_sample_threshold

número de amostras a acumular, padrão 100

time_threshold

limite de tempo, padrão 60.000 ms = 60 segundos

Veja também o modo Assíncrono, descrito abaixo.

Estatística

enviar uma amostra de resumo quando a contagem ou o tempo exceder um limite. As amostras são resumidas pelo nome do grupo de encadeamentos e pelo rótulo da amostra. Os seguintes campos são acumulados:

• Tempo decorrido
• latência
• bytes
• contagem de amostra
• contagem de erros

Outros campos que variam entre as amostras são perdidos.

Despojado

remover responseData de amostras bem-sucedidas

StrippedBatch

remova responseData de amostras bem-sucedidas e use o remetente do Lote para enviá-las.

Assíncrono

as amostras são armazenadas temporariamente em uma fila local. Um thread de trabalho separado envia as amostras. Isso permite que o encadeamento de teste continue sem esperar que o resultado seja enviado de volta ao cliente. No entanto, se as amostras estiverem sendo criadas mais rapidamente do que podem ser enviadas, a fila acabará se enchendo e o encadeamento do amostrador será bloqueado até que algumas amostras possam ser drenadas da fila. Este modo é útil para suavizar picos na geração de amostra. O tamanho da fila pode ser ajustado definindo a propriedade JMeter asynch.batch.queue.size (padrão 100 ) no nó do servidor.

StrippedAsync

remova responseData de amostras bem-sucedidas e use o remetente assíncrono para enviá-las.

Implementação personalizada

defina o parâmetro mode para o nome da classe do remetente de amostra personalizada. Isso deve implementar a interface SampleSender e ter um construtor que receba um único parâmetro do tipo RemoteSampleListener .

As seguintes propriedades se aplicam aos modos Lote e Estatística :

num_sample_threshold

número de amostras em um lote (padrão 100 )

time_threshold

número de milissegundos para esperar (padrão 60 segundos)

13.6 Lidando com nós que falharam ao iniciar ¶

Para testes em grande escala, há uma chance de que alguma parte dos servidores remotos esteja indisponível ou inoperante. Por exemplo, quando você usa o script de automação para alocar muitas máquinas em nuvem e usá-las como geradores, algumas das máquinas solicitadas podem falhar na inicialização devido a problemas na nuvem. Desde o JMeter 2.13 existem novas propriedades para controlar este comportamento.

Primeiro, o que você pode querer é tentar novamente as tentativas de inicialização na esperança de que os nós com falha tenham apenas um pouco de atraso na inicialização. Para habilitar novas tentativas, você deve definir a propriedade client.tries para o número total de tentativas de conexão. Por padrão, ele faz apenas uma tentativa. Para controlar o atraso de novas tentativas, defina a propriedade client.retries_delay para o número de milissegundos de suspensão entre as tentativas.

Por fim, talvez você ainda queira executar o teste com os geradores que obtiveram êxito na inicialização e ignoraram os nós com falha. Para habilitar isso, configure a propriedade client.continue_on_fail=true .

13.7 Usando um gerenciador de segurança ¶

Ao executar o JMeter em um ambiente distribuído, você deve estar ciente de que o JMeter é basicamente um agente de execução remota no lado do servidor e do cliente. Isso pode ser usado por uma parte mal-intencionada para obter acesso adicional, uma vez que tenha comprometido um dos clientes ou servidores JMeter. Para mitigar isso, o Java tem o conceito de um gerenciador de segurança que é solicitado pela JVM antes que ações potencialmente perigosas sejam executadas. Essas ações podem ser resolver nomes de host, criar ou ler arquivos ou executar comandos no sistema operacional.

O gerenciador de segurança pode ser ativado configurando as propriedades do sistema Java java.security.manager e java.security.policy . Certifique-se de dar uma olhada no tour rápido de aplicativos de controle .

Usando o novo mecanismo de setenv.sh (ou setenv.bat no Windows), você pode habilitar o gerenciador de segurança adicionando o seguinte trecho de código a ${JMETER_HOME}/bin/setenv.sh :

JVM_ARGS="\
   -Djava.security.manager \
   -Djava.security.policy=${JMETER_HOME}/bin/java.policy \
   -Djmeter.home=${JMETER_HOME} \
"

A JVM agora incluirá as políticas definidas no arquivo ${JMETER_HOME}/bin/java.policy nas políticas possivelmente definidas globalmente. Se você quiser que sua definição seja a única fonte de políticas, use dois sinais de igual em vez de um ao definir a propriedade java.security.policy .

As políticas dependerão do seu caso de uso e pode demorar um pouco para encontrar as ações restritas e permitidas corretas. Java pode ajudá-lo a encontrar as políticas necessárias com a propriedade java.security.debug . Configure-o para acessar e ele registrará todas as permissões solicitadas. Basta adicionar a seguinte linha ao seu setenv.sh :

JVM_ARGS="${JVM_ARGS} -Djava.security.debug=access"

Pode parecer um pouco estranho, que definimos uma propriedade de sistema Java jmeter.home com o valor de ${JMETER_HOME} . Essa variável será usada no exemplo java.policy para limitar o acesso ao sistema de arquivos e permitir que ele apenas leia a configuração e bibliotecas de JMeters e restrinja o acesso de gravação apenas a locais específicos.

O arquivo de definição de política a seguir foi usado para um teste remoto simples. Você provavelmente terá que ajustar as políticas quando executar cenários mais complexos. Os planos de teste são colocados em algum lugar dentro do diretório inicial dos usuários em um diretório chamado jmeter-testplans . A amostra java.policy se parece com:

grant codeBase "file:${jmeter.home}/bin/*" {
  permissão java.security.AllPermission;
};

grant codeBase "file:${jmeter.home}/lib/jorphan.jar" {
  permissão java.security.AllPermission;
};

grant codeBase "file:${jmeter.home}/lib/log4j-api-2.11.1.jar" {
  permissão java.security.AllPermission;
};

grant codeBase "file:${jmeter.home}/lib/log4j-slf4j-impl-2.11.1.jar" {
  permissão java.security.AllPermission;
};

grant codeBase "file:${jmeter.home}/lib/slf4j-api-1.7.25.jar" {
  permissão java.security.AllPermission;
};

grant codeBase "file:${jmeter.home}/lib/log4j-core-2.11.1.jar" {
  permissão java.security.AllPermission;
};

grant codeBase "file:${jmeter.home}/lib/ext/*" {
  permissão java.security.AllPermission;
};

grant codeBase "file:${jmeter.home}/lib/httpclient-4.5.6.jar" {
  permissão java.net.SocketPermission "*", "conectar, resolver";
};

grant codeBase "file:${jmeter.home}/lib/darcula.jar" {
  permissão java.lang.RuntimePermission "modifyThreadGroup";
};

grant codeBase "file:${jmeter.home}/lib/xercesImpl-2.12.0.jar" {
  permissão java.io.FilePermission "${java.home}/lib/xerces.properties", "ler";
};

grant codeBase "file:${jmeter.home}/lib/groovy-all-2.4.15.jar" {
  permissão groovy.security.GroovyCodeSourcePermission "/groovy/script";
  permissão java.lang.RuntimePermission "accessClassInPackage.sun.reflect";
  permissão java.lang.RuntimePermission "getProtectionDomain";
};

conceder {
  permissão java.io.FilePermission "${jmeter.home}/backups", "ler, escrever";
  permissão java.io.FilePermission "${jmeter.home}/backups/*", "ler, escrever, excluir";
  permissão java.io.FilePermission "${jmeter.home}/bin/upgrade.properties", "read";
  permissão java.io.FilePermission "${jmeter.home}/lib/ext/-", "ler";
  permissão java.io.FilePermission "${jmeter.home}/lib/ext", "ler";
  permissão java.io.FilePermission "${jmeter.home}/lib/-", "ler";
  permissão java.io.FilePermission "${user.home}/jmeter-testplans/-", "ler, escrever";
  permissão java.io.SerializablePermission "enableSubclassImplementation";
  permissão java.lang.reflect.ReflectPermission "suppressAccessChecks";
  permissão java.lang.RuntimePermission "accessClassInPackage.jdk.internal.dynalink.support";
  permissão java.lang.RuntimePermission "accessClassInPackage.sun.awt";
  permissão java.lang.RuntimePermission "accessClassInPackage.sun.misc";
  permissão java.lang.RuntimePermission "accessClassInPackage.sun.swing";
  permissão java.lang.RuntimePermission "accessDeclaredMembers";
  permissão java.lang.RuntimePermission "createClassLoader";
  permissão java.lang.RuntimePermission "createSecurityManager";
  permissão java.lang.RuntimePermission "getClassLoader";
  permissão java.lang.RuntimePermission "getenv.*";
  permissão java.lang.RuntimePermission "nashorn.createGlobal";
  permissão java.util.PropertyPermission "*", "ler";
};