Capitulo 9788575226391 by Ana Carolina Prates

Bayo Erinle

Novatec

Copyright © Packt Publishing 2017. First published in the English language under the title ‘Performance Testing with jMeter 3, Third Edition (9781787285774)’. Copyright © Packt Publishing 2017. Publicação original em inglês intitulada ‘Performance Testing with jMeter 3, Third Edition (9781787285774)’. Esta tradução é publicada e vendida com a permissão da Packt Publishing. © Novatec Editora Ltda. [2017]. Todos os direitos reservados e protegidos pela Lei 9.610 de 19/02/1998. É proibida a reprodução desta obra, mesmo parcial, por qualquer processo, sem prévia autorização, por escrito, do autor e da Editora. Editor: Rubens Prates FC20171114 Tradução: Aldir Coelho Corrêa da Silva Revisão gramatical: Tássia Carvalho Editoração eletrônica: Carolina Kuwabata ISBN: 978-85-7522-639-1 Histórico de impressões: Novembro/2017

Primeira edição

Novatec Editora Ltda. Rua Luís Antônio dos Santos 110 02460-000 – São Paulo, SP – Brasil Tel.: +55 11 2959-6529 Email: novatec@novatec.com.br Site: www.novatec.com.br Twitter: twitter.com/novateceditora Facebook: facebook.com/novatec LinkedIn: linkedin.com/in/novatec

capítulo 1

Fundamentos do teste de desempenho

O teste de desempenho de software é usado para determinar a velocidade ou a eficácia de um computador, rede, programa de software ou dispositivo. Esse processo pode envolver testes quantitativos feitos em um laboratório, como a avaliação do tempo de resposta ou do número de MIPs (milhões de instruções por segundo) com o qual um sistema funciona. – Wikipédia

Consideremos um estudo de caso. A Baysoft Training Inc. é uma startup cuja meta é redefinir como os softwares podem ajudar a treinar cada vez mais pessoas em várias áreas da indústria de TI. A empresa cumpre esse objetivo fornecendo um conjunto de produtos, que inclui cursos online e treinamento presencial e a distância. Logo, um de seus principais produtos – o TrainBot, uma aplicação baseada na web – se destina apenas a registrar pessoas em cursos de interesse que as ajudarão a galgar degraus em suas carreiras. Uma vez registrado, o cliente pode participar de uma série de cursos interativos online.

O incidente Até pouco tempo, o tráfego no TrainBot era pequeno, já que ele só estava aberto para um pequeno número de clientes por ainda se encontrar em versão beta fechada. Tudo estava funcionando e a aplicação como um todo tinha uma ótima capacidade de resposta. Há apenas algumas semanas, o TrainBot foi aberto para o público e tudo continuava funcionando com elegância. Para celebrar a abertura e promover seus cursos de treinamento online, recentemente a Baysoft Training Inc. ofereceu um desconto de 75 por cento em todos os cursos de treinamento. No entanto, essa oferta promocional causou uma repentina corrida ao TrainBot, ultrapassando em muito o que a empresa antecipara. O tráfego na web aumentou em 300 por cento e, subitamente, a situação mudou para pior. 17

Teste de desempenho com JMeter 3

Os recursos de rede não suportaram bem, as CPUs e a memória dos servidores estavam em 90-95 por cento e os servidores de banco de dados não ficaram muito atrás, devido ao alto I/O e contenção. Como resultado, a maioria das solicitações web começou a obter tempos de resposta mais lentos, deixando o TrainBot totalmente não responsivo para grande parte dos clientes novos. Não demorou muito para os servidores travarem e as linhas de suporte ficarem congestionadas depois disso.

O resultado Foi uma longa noite no escritório da Baysoft Training Inc. Como isso ocorreu? Poderia ter sido evitado? Por que a aplicação e o sistema não conseguiram manipular a carga? Por que não foram conduzidos testes de desempenho e de estresse adequados no sistema e na aplicação? Ocorreu um problema na aplicação, nos recursos do sistema ou uma combinação dos dois? A gerência queria que respostas para essas perguntas fossem dadas pelo grupo de engenheiros, composto de desenvolvedores de software, engenheiros de rede e de sistema, testadores de garantia da qualidade (QA, quality assurance) e administradores de banco de dados, que se encontravam na sala de reuniões. É claro que houve acusações e transferência de culpa. Após um pequeno brainstorm, não demorou para o grupo decidir o que precisava ser feito. A aplicação e os recursos do sistema tinham que passar por testes extensos e rigorosos. Isso incluía todas as facetas da aplicação e todos os recursos de suporte do sistema, que englobava, mas não apenas, a infraestrutura, a rede, o banco de dados, os servidores e os balanceadores de carga. Um teste assim ajudaria todas as partes envolvidas a descobrir exatamente onde estavam os gargalos e a resolvê-los adequadamente.

Teste de desempenho O teste de desempenho é um tipo de teste que visa determinar a capacidade de resposta, a confiabilidade, o throughput, a interoperabilidade e a escalabilidade de um sistema e/ou aplicação operando com uma carga de trabalho específica. Ele também pode ser definido como o processo que determina a velocidade ou a eficácia de um computador, rede, aplicação de software ou dispositivo. O teste pode ser conduzido em aplicações de software, recursos do sistema, componentes específicos da aplicação, bancos de dados e muitos outros itens. Normalmente envolve um conjunto de teste automatizado, já que isso permite a execução de simulações fáceis e repetíveis de várias condições de carga normais, extremas e excepcionais.

Capítulo 1 ■ Fundamentos do teste de desempenho

Esses tipos de teste ajudam a verificar se um sistema ou aplicação atende às especificações alegadas por seu fornecedor. O processo pode comparar aplicações em termos de parâmetros como velocidade, taxa de transferência de dados, throughput, largura de banda, eficiência ou confiabilidade. O teste de desempenho também pode ajudar como ferramenta de diagnóstico na determinação de gargalos e pontos de falha individuais. Com frequência ele é conduzido em um ambiente controlado e junto com o teste de estresse – processo que verifica a habilidade de um sistema ou aplicação manter certo nível de eficácia em condições desfavoráveis. Por que se preocupar? Pelo estudo de caso da Baysoft, deve ter ficado claro por que as empresas se preocupam e não medem esforços para conduzir o teste de desempenho. O desastre poderia ter sido minimizado, quando não totalmente evitado, caso um teste de desempenho eficaz tivesse sido conduzido no TrainBot antes de ele ser aberto para o público. À medida que avançarmos por este capítulo, continuaremos examinando os diversos benefícios de um teste de desempenho eficiente. De modo geral, na maioria das vezes, o teste de desempenho é conduzido para detectar um ou mais riscos relacionados a despesas, custos de oportunidade, continuidade e/ou reputação corporativa. A condução desses testes ajuda a mostrar se uma aplicação de software está pronta para ser lançada, se os recursos de rede e do sistema são satisfatórios, se a infraestrutura é estável e se a aplicação é escalável, para citar apenas alguns benefícios. A coleta de características estimadas de desempenho da aplicação e dos recursos do sistema antes do lançamento ajuda a resolver problemas de maneira antecipada e fornece um feedback valioso para os stakeholders, ajudando-os a tomar decisões estratégicas importantes. O teste de desempenho tem grande abrangência, incluindo áreas como as seguintes: • Definição sobre se a aplicação e o sistema estão prontos para o ambiente de produção • Avaliação em relação a critérios de desempenho (por exemplo, transações por segundo, visualizações de páginas por dia e registros diários) • Comparação de características de desempenho de vários sistemas ou configurações de sistema • Identificação da fonte de gargalos no desempenho • Ajuda no ajuste do desempenho e do sistema • Ajuda na identificação dos níveis de throughput do sistema • Atuação como ferramenta de teste

Teste de desempenho com JMeter 3

Quase todas essas áreas estão interligadas e cada aspecto contribui para o cumprimento dos objetivos gerais dos stakeholders. Porém, antes de abordar o tema central, faremos uma pausa para entender as atividades básicas da condução de testes de desempenho mostradas a seguir: • Identificação de critérios de aceitação: Qual é o desempenho aceitável para os vários módulos da aplicação quando submetidos à carga? Especificamente, precisamos identificar os objetivos e as restrições referentes ao tempo de resposta, ao throughput e à utilização de recursos. Por quanto tempo o usuário final deve esperar até uma página específica ser renderizada? Por quanto tempo ele deve esperar para executar uma operação? Geralmente o tempo de resposta é um problema referente ao usuário, o throughput é um problema referente à corporação, e a utilização de recursos é um problema referente ao sistema. Logo, o tempo de resposta, o throughput e a utilização de recursos são aspectos-chave do teste de desempenho. Os critérios de aceitação costumam ser definidos pelos stakeholders, e é importante envolvê-los continuamente conforme o teste avança, já que os parâmetros talvez precisem ser revisados. • Identificação do ambiente de teste: Familiarizar-se com os ambientes físicos de teste e produção é crucial para uma execução de teste bem-sucedida. Conhecer coisas como as configurações de hardware, software e rede do ambiente ajuda na derivação de um plano de teste eficaz e na identificação dos desafios do teste desde o início. Quase sempre, esses itens são revisitados e/ou revisados durante o ciclo de teste. • Planejamento e design de testes: Conhecer o padrão de uso da aplicação (se houver) e criar cenários realistas, com a inclusão de variabilidade entre os diversos cenários. Por exemplo, se a aplicação em questão tiver um módulo de registro de usuários, normalmente quantos usuários se registrarão para obter uma conta em um dia? Esses registros ocorrerão todos de uma vez, ao mesmo tempo, ou serão espaçados? Quantas pessoas frequentarão a página inicial da aplicação no período de uma hora? Perguntas como essas ajudam a dar uma visão geral das coisas e a fornecer variações de design para o plano de teste. Contudo, algumas vezes a aplicação a ser testada é nova e, portanto, ainda não há um padrão de uso. Nesses casos, os stakeholders devem ser consultados para explicar seu processo operacional e sugerir um plano de teste o mais realista possível.

Capítulo 1 ■ Fundamentos do teste de desempenho

• Preparação do ambiente de teste: Configurar o ambiente, as ferramentas e os recursos de teste necessários para a condução dos cenários de teste planejados. É importante assegurar que o ambiente de teste seja instrumentado com um monitoramento de recursos que ajude a analisar os resultados com mais eficiência. Dependendo da empresa, uma equipe poderia ficar responsável por definir as ferramentas de teste e outra por configurar os demais aspectos como o monitoramento de recursos. Em outras corporações, uma única equipe pode ser suficiente para definir todos os aspectos. • Preparação do plano de teste: Usando uma ferramenta de teste, grave os cenários de teste planejados. Há várias ferramentas de teste disponíveis, tanto gratuitas quanto comerciais, que fazem isso muito bem, e todas têm suas vantagens e desvantagens. • Essas ferramentas são o HP LoadRunner, NeoLoad, LoadUI, Gatling, WebLOAD, WAPT, Loadster, Load Impact, Rational Performance Tester, Testing Anywhere, OpenSTA, LoadStorm, The Grinder, Apache Benchmark, httpref e assim por diante. Algumas são comerciais enquanto outras não são tão maduras, portáveis ou extensíveis quanto o JMeter. O HP LoadRunner, por exemplo, é caro e restringe a 250 o número de threads simuladas sem a compra de licenças adicionais, embora ofereça uma interface gráfica e um recurso de monitoramento melhores. O Gatling, a grande novidade, é gratuito e parece promissor. Ele ainda é muito novo, tem por objetivo resolver algumas das deficiências do JMeter e inclui testes mais fáceis com linguagem de domínio específico (DSL, domain-specific language) versus o XML verboso do JMeter e relatórios HTML melhores e mais significativos, entre outros. • Mesmo assim, por enquanto ainda tem uma base de usuários minúscula se comparado com o JMeter e não é qualquer pessoa que se sente à vontade com a construção de planos de teste no Scala, sua linguagem preferencial. Os programadores podem achá-lo mais interessante. • Neste livro, a ferramenta que escolhemos para a execução dessa etapa é o Apache JMeter. Isso não deve surpreender se considerarmos o título. • Execução dos testes: Uma vez que os planos de teste tiverem sido gravados, execute-os com carga leve e verifique se os scripts de teste e os resultados exibidos na saída estão corretos. Em casos em que dados de teste ou de entrada forem fornecidos aos scripts para simular dados mais realistas (veremos mais sobre isso nos capítulos subsequentes), valide também os

Teste de desempenho com JMeter 3

dados de teste. Outro aspecto ao qual deve ser dada muita atenção durante a execução do plano de teste são os logs de servidor. Isso pode ser feito por intermédio dos agentes de monitoramento de recursos definidos para monitorar os servidores. É crucial prestar atenção a avisos e erros. Uma alta taxa de erros, por exemplo, pode indicar que há algo errado com os scripts de teste, com a aplicação ao qual o teste está sendo aplicado, com o recurso do sistema ou uma combinação de tudo isso. • Análise de resultados, relatório e novo teste: Examine os resultados de cada execução sucessiva e identifique áreas com gargalos que precisem ser resolvidos. Eles podem estar relacionados ao sistema, ao banco de dados ou à aplicação. Gargalos relacionados ao sistema podem levar a alterações na infraestrutura, como o aumento da memória disponível para a aplicação, a redução de consumo da CPU, o aumento ou a diminuição dos tamanhos de pools de threads, a revisão dos tamanhos de pools do banco de dados e a redefinição de configurações de rede. Os gargalos relacionados ao banco de dados podem levar à análise de operações de I/O, à verificação das principais consultas feitas pela aplicação submetida a teste, à análise de perfil das consultas SQL, à introdução de índices adicionais, à execução de coleta de estatísticas, à alteração dos tamanhos e dos locks de páginas das tabelas e muito mais. Para concluir, alterações relacionadas à aplicação podem levar a atividades como a refatoração de componentes da aplicação e a redução de consumo da memória e de round trips ao banco de dados. Uma vez que os gargalos identificados forem resolvidos, os testes devem ser reexecutados e comparados com as execuções anteriores.

Para ajudar a rastrear que alteração ou grupo de alterações resolveu um gargalo específico, é vital que as alterações sejam aplicadas ordenadamente, de preferência uma de cada vez. Em outras palavras, uma vez que uma alteração for aplicada, o mesmo plano de teste será executado e os resultados serão comparados com uma execução anterior para verificarmos se a alteração os melhorou ou piorou. Esse processo é repetido até os objetivos de desempenho do projeto serem atingidos.

A Figura 1.1 mostra como as atividades básicas do teste de desempenho poderiam ser exibidas. Geralmente o teste de desempenho é um esforço colaborativo entre todas as partes envolvidas, as quais incluem os stakeholders, os arquitetos empresariais, desenvolvedores, testadores, DBAs, administradores de sistema e administradores de rede. A colaboração é necessária para a coleta eficaz de resultados precisos e importantes

Capítulo 1 ■ Fundamentos do teste de desempenho

na condução dos testes. O monitoramento da utilização de rede, de I/O e esperas do banco de dados, das principais consultas e da contagem de chamadas ajudará a equipe a encontrar gargalos e áreas que precisem de maior atenção em esforços de ajuste contínuo.

Figura 1.1 – Atividades básicas do teste de desempenho.

Teste e ajuste de desempenho Há uma forte relação entre o teste e o ajuste do desempenho, já que com frequência um leva ao outro. Geralmente, o teste end-to-end revela gargalos no sistema ou na aplicação que são considerados inaceitáveis para os objetivos do projeto. Quando esses gargalos são descobertos, a próxima etapa para a maioria das equipes é uma série de esforços de ajuste que façam a aplicação ser executada adequadamente. Em geral, esses esforços incluem as seguintes ações (sem se limitar a elas): • Alterações na configuração de recursos do sistema • Redução de round trips em chamadas da aplicação, às vezes levando a um novo design e arquitetura de módulos problemáticos

Teste de desempenho com JMeter 3

• Aumento da capacidade do servidor da aplicação e do banco de dados • Redução do footprint de recursos da aplicação • Otimização e refatoração de código, incluindo a eliminação de redundância e a redução do tempo de execução Os esforços de ajuste também podem começar se a aplicação tiver alcançado um desempenho aceitável, mas a equipe quiser reduzir o número de recursos usados no sistema, diminuir o volume de hardware necessário ou melhorar ainda mais o desempenho do sistema. Após cada alteração (ou série de alterações), o teste é reexecutado para sabermos se ela melhorou ou piorou o desempenho. O processo dará continuidade com os resultados do desempenho alcançando metas aceitáveis. Normalmente o efeito desses ciclos de ajuste por teste produz uma linha de base.

Linhas de base A obtenção de linhas de base (baseline) é o processo de captura de métricas de desempenho com a finalidade exclusiva de avaliação da eficácia de alterações sucessivas no sistema ou aplicação. É importante que todas as características e configurações, exceto as que estiverem sendo mudadas para confrontação, permaneçam iguais a fim de proporcionar comparações eficazes em relação a que alteração (ou série de alterações) está conduzindo os resultados em direção à meta desejada. Com a obtenção desses resultados de linha de base, alterações subsequentes poderão ser feitas na configuração do sistema ou na aplicação e os resultados do teste poderão ser comparados para sabermos se elas foram ou não relevantes. Alguns itens que devem ser levados em consideração na geração de linhas de base são: • Elas são específicas da aplicação • Podem ser criadas para sistemas, aplicações ou módulos • São métricas/resultados • Não devem ser excessivamente generalizadas • Elas evoluem e talvez precisem ser redefinidas com o passar do tempo • Agem como um referencial compartilhado • São reutilizáveis • Ajudam a identificar mudanças no desempenho

Capítulo 1 ■ Fundamentos do teste de desempenho

Teste de carga e de estresse Teste de carga é o processo de forçar o desempenho de um sistema e medir sua resposta, isto é, determinar que volume ele consegue manipular. Teste de estresse é o processo de sujeitar o sistema a cargas excepcionalmente altas, bem além de seu padrão de uso normal, para determinar sua capacidade de resposta. Eles são diferentes do teste de desempenho, cuja única finalidade é detectar a resposta e a eficácia de um sistema, ou seja, o quanto ele é rápido. Já que a carga afeta significativamente como um sistema responde, o teste de desempenho costuma ser feito junto com o teste de estresse.

O JMeter veio ao socorro Na última seção, abordamos os fundamentos da condução de um teste de desempenho. Uma das áreas que o teste de desempenho abrange é a das ferramentas de teste. Que ferramenta de teste você deve usar para fazer o sistema e a aplicação mostrarem como suportam carga? Há várias ferramentas de teste disponíveis para a execução dessa operação, de soluções gratuitas a comerciais. No entanto, neste livro daremos ênfase ao Apache JMeter, uma aplicação desktop gratuita, open source e multiplataforma da Apache Software Foundation. O JMeter foi lançado em 1998 de acordo com os registros do histórico de alterações de seu site oficial, o que o torna uma ferramenta de teste madura, robusta e confiável. O custo também pode ter influenciado sua ampla adoção. Geralmente pequenas empresas não querem pagar por ferramentas de teste provenientes de entidades comerciais, que com frequência impõem restrições a, por exemplo, quantos usuários simultâneos podem ser incluídos no teste. Meu primeiro encontro com o JMeter ocorreu exatamente por esse problema. Eu trabalhava em uma pequena loja que tinha comprado uma ferramenta de teste comercial, mas, no decorrer do teste, excedemos os limites do licenciamento referentes a quantos usuários simultâneos poderíamos simular para ter planos de teste realistas. Já que o JMeter era gratuito, nós o examinamos e ficamos encantados com as vantagens e o número de recursos que obteríamos sem custo. Vejamos alguns de seus recursos: • Testes de desempenho de diferentes tipos de servidor, inclusive web (HTTP e HTTPS), SOAP, de banco de dados, LDAP, JMS e de email, e shell scripts ou comandos nativos • Portabilidade total entre vários sistemas operacionais

Teste de desempenho com JMeter 3

• Framework multithreading completo que fornece a amostragem concorrente de vários threads e a amostragem simultânea de diferentes funções de grupos de threads distintos • IDE de teste com todos os recursos, o que permite a rápida gravação, construção e depuração de planos de teste • Relatório em painel para a análise detalhada de índices de desempenho e transações-chave da aplicação • Integração interna com ferramentas de relatório e análise em tempo real, como o Graphite, o InfluxDB e o Grafana, para citar apenas algumas • Relatórios HTML completos e dinâmicos • Interface gráfica de usuário (GUI) • Servidor proxy HTTP de gravação • Cache e análise/reprodução offline de resultados de teste • Alta extensibilidade • Visualização dinâmica de resultados à medida que o teste é conduzido O JMeter permite que vários usuários simultâneos sejam simulados na aplicação, o que nos possibilita trabalhar visando atingir a maioria dos objetivos descritos anteriormente neste capítulo, como obter linhas de base e identificar gargalos. Isso ajudará a responder a perguntas como as seguintes: • A aplicação continuará tendo boa capacidade de resposta se 50 usuários o acessarem simultaneamente? • Que nível de confiança ele terá com uma carga de 200 usuários? • Que quantidade de recursos do sistema será consumida com uma carga de 250 usuários? • Como será o throughput com 1000 usuários ativos no sistema? • Qual será o tempo de resposta dos diversos componentes da aplicação suportando carga?

Capítulo 1 ■ Fundamentos do teste de desempenho

No entanto, o JMeter não deve ser confundido com um navegador (veremos mais sobre isso no Capítulo 2, Gravando seu primeiro teste, e no Capítulo 3, Enviando formulários). Ele não executa todas as operações suportadas pelos navegadores; em particular, o JMeter não executa o JavaScript encontrado em páginas HTML, assim como também não renderiza páginas HTML como o faz o navegador. Contudo, ele nos permite visualizar respostas a solicitações como HTML por intermédio de seus listeners, embora informações de tempo não sejam incluídas nas amostragens. Além disso, há limitações para quantos usuários podem ser considerados em uma única máquina. Isso varia dependendo das especificações da máquina (por exemplo, memória, velocidade do processador e assim por diante) e dos cenários de teste sendo executados. Em nosso caso, obtivemos sucesso ao incluir 250-450 usuários em uma única máquina com processador de 2.2 GHz e 8 GB de RAM.

Instalação e execução do JMeter Agora, passaremos a usar o JMeter, começando com sua instalação.

Instalação O JMeter vem empacotado em um archive, logo, é muito fácil começar a usá-lo. Quem trabalha em ambientes corporativos protegidos por um firewall ou máquinas sem privilégios administrativos apreciará ainda mais essa característica. Para começar, obtenha a última versão binária apontando seu navegador para http://jmeter. apache.org/download_jmeter.cgi. Quando esse texto foi escrito, a versão atual era a 3.1. O site de download oferece o pacote tanto como um arquivo .zip quanto como um arquivo .tgz. Neste livro, usaremos a opção de arquivo .zip, mas sinta-se à vontade para baixar o arquivo .tgz se essa for sua maneira preferida de capturar archives. Depois de baixar, extraia o archive para um local de sua escolha. No decorrer deste livro, o local para o qual o archive foi extraído será chamado de JMETER_HOME. Se você tiver um JDK/JRE instalado corretamente e uma variável de ambiente JAVA_HOME definida, estará pronto para começar a execução! A Figura 1.2 mostra a estrutura de diretório parcial de uma instalação vanilla do JMeter:

Teste de desempenho com JMeter 3

Figura 1.2 – Estrutura de pastas de JMETER_HOME.

Essas são algumas das pastas do Apache-JMeter-3.2, como mostrado na Figura 1.2: • bin – Essa pasta contém scripts executáveis que processam outras operações no JMeter • docs – Essa pasta contém um guia do usuário bem documentado • extras – Essa pasta contém itens variados, inclusive amostragens que ilustram o uso da ferramenta de build Apache Ant (http://ant.apache.org/) com o JMeter e o bean shell scripting • lib – Essa pasta contém arquivos JAR utilitários requeridos pelo JMeter (você pode adicionar outros JARs aqui para usar de dentro do JMeter; abordaremos isso com detalhes posteriormente) • printable_docs – Essa é a documentação imprimível

Capítulo 1 ■ Fundamentos do teste de desempenho

Instalando o JDK Java Siga essas etapas para instalar o JDK Java: 1. Acesse http://www.oracle.com/technetwork/java/javase/downloads/index.html.

2. Baixe o JDK Java (e não o JRE) compatível com o sistema que você usará para testar. Quando esse texto foi escrito, o JDK 1.8 (atualização 131) era o mais recente, e é ele que usaremos no restante do livro. 3. Clique duas vezes no executável e siga as instruções na tela. Em sistemas Windows, o local-padrão do JDK fica sob Program Files. Embora não haja nada de errado nisso, o problema é que o nome da pasta contém um espaço, o que às vezes pode dificultar definir PATH e executar programas, como o JMeter, na linha de comando dependendo do JDK. Logo, é aconselhável alterar o local-padrão para algo como C:\tools\jdk.

Definindo JAVA_HOME A seguir temos as etapas para a definição da variável de ambiente JAVA_HOME em sistemas operacionais Windows e Unix.

No Windows Para fins ilustrativos, presumiremos que você instalou o JDK Java em C:\tools\jdk: 1. Acesse o Control Panel. 2. Clique em System. 3. Clique em Advance System settings. 4. Adicione os seguintes valores da variável de ambiente: • Nome: JAVA_HOME • Valor: C:\tools\jdk 5. Localize Path (em variáveis do sistema, na metade inferior da tela). 6. Clique em Edit. 7. Acrescente %JAVA_HOME%/bin ao fim do valor do path existente (se houver algum).

Teste de desempenho com JMeter 3

No Unix Para fins ilustrativos, presumiremos que você instalou o JDK Java em /opt/tools/jdk: 1. Abra uma janela de terminal. 2. Exporte JAVA_HOME=/opt/tools/jdk. 3. Exporte PATH=$PATH:$JAVA_HOME. É aconselhável definir esses valores nas configurações de perfil de shell, como em .bash_profile (para usuários do bash) ou .zshrc (para usuários do zsh), para que você não tenha de defini-los para cada nova janela de terminal que abrir.

Executando o JMeter Após a instalação, a pasta bin que fica na pasta JMETER_HOME conterá todos os scripts executáveis que poderão ser usados. Dependendo do sistema operacional em que o JMeter estiver instalado, você executará os shell scripts (arquivo .sh) para sistemas operacionais de tipo Unix/Linux, ou suas contrapartidas batch (arquivo .bat) em sistemas operacionais de tipo Windows. Os arquivos do JMeter são salvos como arquivos XML com extensão .jmx. Neste livro, vamos chamá-los de scripts de teste ou arquivos JMX.

Esses scripts são os seguintes: • jmeter.sh – Script que inicia a GUI do JMeter (o padrão) • jmeter-n.sh – Script que inicia o JMeter no modo sem GUI (recebe um arquivo XML como entrada) • jmeter-n-r.sh – Script que inicia o JMeter no modo sem GUI remotamente • jmeter-t.sh – Abre um arquivo XML na GUI • jmeter-server.sh – Script que inicia o JMeter no modo de servidor (é executado no nó mestre em casos de teste com várias máquinas remotamente; veremos mais sobre isso no Capítulo 6, Teste distribuído) • mirror-server.sh – Script que executa o servidor espelho do JMeter • shutdown.sh – Script que encerra normalmente uma instância em execução sem GUI • stoptest.sh – Script que encerra abruptamente uma instância em execução sem GUI

Capítulo 1 ■ Fundamentos do teste de desempenho

Para iniciar o JMeter, abra um shell de terminal, passe para a pasta JMETER_HOME/bin e execute o comando a seguir no Unix/Linux: ./jmeter.sh

Alternativamente, execute o comando a seguir no Windows: jmeter.bat

Logo depois, você verá a GUI do JMeter exibida na seção de configuração do servidor proxy. Dedique algum tempo à exploração da GUI. Passe o mouse sobre cada ícone para ver uma breve descrição do que ele faz. A equipe do Apache JMeter fez um ótimo trabalho na GUI. Quase todos os ícones são muito semelhantes àqueles com os quais estamos acostumados, o que ajuda a abrandar a curva de aprendizado para novos adeptos. Alguns dos ícones, por exemplo, stop e shutdown, ficarão desativados até um cenário/teste ser conduzido. No próximo capítulo, examinaremos a GUI com mais detalhes ao gravar nosso primeiro script de teste. A variável de ambiente VM_ARGS pode ser usada para sobrepor as configurações de JVM do script jmeter.bat ou jmeter.sh. Veja o exemplo a seguir: export JVM_ARGS="-Xms1024m -Xmx1024m -Dpropname=propvalue".

Opções de linha de comando Para ver todas as opções disponíveis para inicialização do software, inicie o executável do JMeter com o comando -?. As opções fornecidas são as seguintes: ./jmeter.sh -? -? print command line options and exit -h, --help print usage information and exit -v, --version print the version information and exit -p, --propfile <argument> the jmeter property file to use -q, --addprop <argument> additional JMeter property file(s) -t, --testfile <argument> the jmeter test(.jmx) file to run -l, --logfile <argument> the file to log samples to

Teste de desempenho com JMeter 3 -j, --jmeterlogfile <argument> jmeter run log file (jmeter.log) -n, --nongui run JMeter in nongui mode ... -J, --jmeterproperty <argument>=<value> Define additional JMeter properties -G, --globalproperty <argument>=<value> Define Global properties (sent to servers) e.g. -Gport=123 or -Gglobal.properties -D, --systemproperty <argument>=<value> Define additional system properties -S, --systemPropertyFile <argument> additional system property file(s)

Esse é um fragmento (e não uma lista completa) do que você deve ver se fizer o mesmo. Examinaremos algumas dessas opções, mas não todas, no decorrer do livro.

Classpath do JMeter Já que o JMeter é 100 por cento Java, ele vem com funcionalidades que nos permitem aproveitar ao máximo os casos de teste com scripts. No entanto, pode chegar um momento em que você precise trazer uma funcionalidade fornecida por uma biblioteca de terceiros, ou desenvolvida por sua própria conta, que não esteja presente por padrão. Nesse caso, o JMeter oferece dois diretórios em que bibliotecas de terceiros podem ser inseridas para que sejam encontradas automaticamente em seu caminho de classe: • JMETER_HOME/lib – Usado para JARs utilitários. • JMETER_HOME/lib/ext – Usado para componentes e complementos do JMeter. Todos os componentes do JMeter desenvolvidos de forma personalizada devem ser inseridos na pasta lib/ext, enquanto bibliotecas de terceiros (arquivos JAR) devem residir na pasta lib.

Configurando um servidor proxy Se você estiver trabalhando protegido por um firewall corporativo, pode ter de configurar o JMeter para interagir com ele, fornecendo o host e o número de porta do servidor proxy.

Capítulo 1 ■ Fundamentos do teste de desempenho

Para fazê-lo, passe parâmetros de linha de comando adicionais para o JMeter ao inicializá-lo. Alguns deles são: -H Esse parâmetro de linha de comando especifica o nome de host ou o endereço

IP do servidor proxy -P Esse especifica a porta do servidor proxy -u Especifica o nome de usuário do servidor proxy se for seguro -a Especifica a senha do servidor proxy se for seguro; veja o exemplo a seguir: ./jmeter.sh -H proxy.server -P 7567 -u username -a password

No Windows, execute o arquivo jmeter.bat. Não confunda o servidor proxy mencionado aqui com o Gravador de Scripts de Teste HTTP(S) interno do JMeter, o qual é usado para gravar sessões de navegador HTTP ou HTTPS. Examinaremos isso no próximo capítulo ao gravarmos nosso primeiro cenário de teste.

A tela é exibida da seguinte forma (Figura 1.3):

Figura 1.3 – GUI do JMeter.

Teste de desempenho com JMeter 3

Execução no modo sem GUI Como descrito anteriormente, o JMeter pode ser executado no modo sem GUI. Isso será necessário em caso de execução remota ou se você quiser otimizar seu sistema de teste não incorrendo no custo de overhead adicional de execução da GUI. Em geral, você fará a execução no modo padrão (com GUI) quando preparar scripts de teste e usar carga leve, mas empregará o modo sem GUI para cargas mais altas. Para iniciar o modo sem GUI, use as seguintes opções de linha de comando: -n Essa opção de linha de comando indica execução no modo sem GUI -t Essa opção de linha de comando especifica o nome do arquivo de teste JMX -l Essa opção de linha de comando especifica o nome do arquivo JTL no qual

serão registrados os resultados -j Essa opção de linha de comando especifica o nome do arquivo de log de

execução do JMeter -r Essa opção de linha de comando executa os servidores de teste especificados pela propriedade remote_hosts do JMeter -R Essa opção de linha de comando executa o teste nos servidores remotos especificados (por exemplo, -Rserver1, server2)

Você também pode usar as opções -H e -P para especificar o host e a porta do servidor proxy, como descrito anteriormente: ./jmeter.sh -n -t test_plan_01.jmx -l log.jtl

Execução no modo de servidor Essa alternativa é usada na execução do teste distribuído, isto é, no uso de mais servidores de teste para gerar carga adicional no sistema. O JMeter será iniciado no modo de servidor em cada servidor remoto (escravo) e, em seguida, uma GUI do servidor mestre será usada para controlar os nós escravos. Discutiremos isso com detalhes quando examinarmos o teste distribuído no Capítulo 4, Gerenciando sessões: ./jmeter-server.sh

Especifique a propriedade server.exitaftertest=true do JMeter se quiser que o servidor seja encerrado depois de um único teste ser concluído. Ela vem desativada por padrão.

Capítulo 1 ■ Fundamentos do teste de desempenho

Sobrepondo propriedades O JMeter fornece duas maneiras de sobrepor propriedades dele próprio, de Java e de logging. Uma maneira é editar diretamente jmeter.properties, que reside na pasta JMETER_HOME/bin. Sugiro que você examine esse arquivo e veja o grande número de propriedades que podem ser sobrepostas. Essa é uma das coisas que tornam o JMeter tão poderoso e flexível. Na maioria dos casos, não é preciso sobrepor os padrões, porque eles já têm os valores corretos. A outra maneira de sobrepor esses valores é a partir da linha de comando na inicialização do JMeter. As opções disponíveis são as seguintes: • Definição do valor de uma propriedade Java do sistema: -D<nome_propriedade>=<value>

• Definição de uma propriedade local do JMeter: -J<nome_propriedade>=<value>

• Definição de uma propriedade do JMeter para ser enviada para todos os servidores remotos: -G<nome_propriedade>=<value>

• Definição de um arquivo contendo propriedades do JMeter para ser enviado para todos os servidores remotos: -G<nome_propriedade>

• Sobreposição de uma configuração de logging, com a definição de uma categoria com um nível de prioridade fornecido: -L<categoria>=<prioridade> ./jmeter.sh -Duser.dir=/home/bobbyflare/jmeter_stuff -Jremote_hosts=127.0.0.1 -Ljmeter.engine=DEBUG

Já que as opções de linha de comando são processadas depois de o sistema de logging ter sido configurado, qualquer tentativa de usar a flag -J para atualizar a propriedade log_level ou log_file não terá efeito.

Teste de desempenho com JMeter 3

Rastreando erros durante a execução do teste O JMeter registra todos os erros que ocorrem durante um teste em um arquivo de log chamado jmeter.log por padrão. O arquivo reside na pasta a partir da qual o JMeter foi iniciado. Como quase tudo, o nome desse arquivo de log pode ser configurado em jmeter.properties, ou por intermédio do parâmetro de linha de comando -j <nome_arquivo_log>. Quando a GUI é executada, a contagem de erros é exibida no canto superior direito, isto é, à esquerda do número de threads que estão sendo executados para o teste, como mostrado na screenshot a seguir (Figura 1.4). Clicar nela revela o conteúdo do arquivo de log na parte inferior da GUI. O arquivo de log dá uma ideia do que está ocorrendo no JMeter enquanto os testes são executados e ajuda a determinar a causa de erros quando eles ocorrem:

Figura 1.4 – Contagem/indicador de erros da GUI do JMeter.

Configurando o JMeter Se você precisar personalizar os valores padrão do JMeter, pode editar o arquivo jmeter.properties na pasta JMETER_HOME/bin ou fazer uma cópia dele, nomeá-la com algo diferente (por exemplo, my-jmeter.properties) e especificar isso como uma opção de linha de comando quando iniciar o JMeter. Algumas opções que você pode configurar são: • xml.parser – Especifica a implementação personalizada do parser XML. O valor padrão é org.apache.xerces.parsers.SAXParser; ele não é obrigatório. Se você achar o parser SAX problemático para alguns de seus casos de uso, há a opção de sobrepô-lo com outra implementação. Por exemplo, você pode usar javax.xml.parsers.SAXParser, contanto que os JARs certos estejam presentes em sua instância de classpath do JMeter. • remote_hosts – Lista delimitada por vírgulas de hosts JMeter remotos (ou host:port se necessário). Quando o JMeter é executado em um ambiente distribuído, lista as máquinas em que servidores JMeter remotos estão sendo executados. Isso permite controlar esses servidores a partir da GUI dessa máquina. Só é aplicável ao teste distribuído e não é obrigatório. Discutiremos mais sobre esse assunto no Capítulo 6, Teste distribuído.

Capítulo 1 ■ Fundamentos do teste de desempenho

• not_in_menu – Lista de componentes cuja exibição pode não ser desejada nos menus do JMeter. Já que o JMeter tem um grande número de componentes, você pode querer limitá-lo a exibir apenas componentes de seu interesse ou que sejam usados com regularidade. Se o nome ou o rótulo de sua classe (a string que aparece na UI do JMeter) for listado aqui, ele não aparecerá mais nos menus. Os padrões são adequados e, em nossa experiência, nunca tivemos de personalizá-los, mas listamos essa opção para que você saiba de sua existência; ela não é obrigatória. • user.properties – Especifica o nome do arquivo que contém propriedades adicionais do JMeter. Elas são adicionadas após o arquivo de propriedades inicial, mas antes de as opções -q e -J serem processadas. Essa opção não é obrigatória. Propriedades do usuário podem ser usadas para fornecer configurações de caminhos de classe adicionais, como caminhos de plugins por intermédio do atributo search_paths e caminhos de JARs utilitários por meio do atributo user_classpath. Esses arquivos de propriedades também podem ser usados no ajuste da verbosidade do log de componentes do JMeter. • search_paths – Especifica uma lista de paths (separados por ;) nos quais o JMeter procurará classes de complementos; por exemplo, samplers adicionais. Trata-se de um acréscimo aos JARs encontrados na pasta lib/ext. Não é obrigatório. Essa opção é útil, por exemplo, para a extensão do JMeter com plugins adicionais que você não pretenda instalar na pasta JMETER_HOME/lib/ext. Podemos usá-la para especificar um local alternativo na máquina para seleção dos plugins. Consulte o Capítulo 4, Gerenciando sessões. • user.classpath – Além dos JARs da pasta lib, use esse atributo para fornecer paths adicionais nos quais o JMeter possa procurar classes utilitárias. Não é obrigatório. • system.properties – Especifica o nome do arquivo que contém propriedades do sistema adicionais para o JMeter usar. Elas são adicionadas antes de as opções -S e -D serem processadas. Essa não é uma opção obrigatória; normalmente ela permite ajustar várias configurações SSL, armazenamentos de chaves e certificados. • ssl.provider – Especifica uma implementação personalizada do SSL se você não quiser usar a implementação interna de Java; não é uma opção obrigatória. Se, por alguma razão, a implementação padrão do SSL oferecida por Java, que é bastante robusta, não atender a seu cenário de uso específico, essa opção permitirá que você forneça uma personalizada. Em nossa experiência, o padrão sempre foi suficiente.

Teste de desempenho com JMeter 3

As opções de linha de comando são processadas na seguinte ordem: • -p profile – Especifica o arquivo jmeter properties personalizado a ser usado. Se presente, ele será carregado e processado. Essa configuração é opcional. • jmeter.properties – É o arquivo de configuração padrão do JMeter e já vem preenchido com valores padrão adequados. Ele é carregado e processado após qualquer arquivo de propriedades personalizado fornecido pelo usuário. • -j logfile – Essa configuração é opcional; especifica o jmeter logfile. Ele será carregado e processado após o arquivo jmeter.properties discutido anteriormente. O logging é inicializado. • user.properties – Esse arquivo (se houver) será carregado. • system.properties – Esse arquivo (se houver) será carregado. Todas as outras opções de linha de comando são processadas.

Resumo Neste capítulo, abordamos os fundamentos do teste de desempenho. Também discutimos os principais conceitos e atividades que em geral o norteiam. Além disso, instalamos o JMeter, e você aprendeu a executá-lo corretamente em uma máquina e examinou algumas das configurações que ele disponibiliza. Exploramos certas vantagens que tornam o JMeter uma ótima ferramenta para sua próxima tarefa de teste de desempenho. Elas incluem o fato de o software ser gratuito e maduro, open source, facilmente extensível e personalizável, totalmente portável entre vários sistemas operacionais, ser um excelente ecossistema de plugins, ter uma ampla comunidade de usuários, ter recurso de gravação e GUI internos, e validar cenários de teste, entre outros. Em comparação com as demais ferramentas de teste de desempenho, o JMeter tem um lugar a ocupar. No próximo capítulo, gravaremos nosso primeiro cenário de teste e nos aprofundaremos no JMeter.