Monitoração – Parte III: As polêmicas métricas sistêmicas

Boas, Esse é o terceiro post da série sobre monitoração. Dê uma lida nos anteriores aqui:

Agora é a hora de falarmos sobre a Monitoração de Sistema (ou sistêmica), que muitas vezes gera bastante polêmica especialmente por causa do seu conceito e de quanto tempo devemos deixar essa monitoração ativa, pois pode influenciar no desempenho geral da aplicação. Quanto ao conceito, vamos levar em consideração o que foi apresentado na Parte I dessa série, mas se você não quiser dar uma lida em todo o post anterior, vou colocar um resuminho.

[box title=”Métricas de Sistema” icon=”info”]Essa etapa de monitoração é como se fosse um segundo nível da informação levantada durante a monitoração de infraestrutura. Há nesse nível uma abstração maior dos bits e bytes que compõem as aplicações e começa-se a pensar um pouco mais nos itens fundamentais para funcionamento correto do sistema e na experiência de uso da aplicação para o usuário.[/box]

Como as métricas de sistema dependem muito das tecnologias que estão envolvidas no desenho da aplicação, não é possível cobrirmos todas as tecnologias existentes, portanto vamos citar as mais comuns quando falamos de aplicações corporativas e para a web.

Outro importante ponto a levantar é que as métricas que serão citadas são, em sua maioria, básicas e servem para direcionar a avaliação de performance. Caso seja necessária uma análise mais aprofundada, novas execuções do teste devem ser realizadas e novos contadores devem ser coletados, de acordo com os problemas iniciais apontados pelas métricas básicas.

Servidores Web

monit03_02

Nos desenhos de arquitetura de aplicações que encontramos nas empresas, de longe os servidores web mais comuns são Apache (e suas variações, como IHS e OHS, criadas pelas grandes empresas) e IIS, para aplicações .NET. Independente de qual servidor web você está usando, as métricas são praticamente as mesma, havendo diferenças apenas na forma como elas são coletadas, e esse tipo de informação pode ser encontrada facilmente na internet.

O que precisamos saber dessa camada é basicamente o tempo médio de resposta de cada requisição, que pode ser conseguido através do time-taken, opção dentro do access log do servidor web. Para um posterior troubleshooting dos possíveis problemas acontecidos durante a execução dos testes, recomenda-se também a coleta e análise do error log, ou log de erros do servidor web.

Algumas métricas se utilização do Apache podem ser obtidas através da habilitação de um module chamado mod_status e de um parâmetro específico desse módulo chamado ExtendedStatus. No IIS, métricas similares podem ser encontradas dentro dos grupos de contadores Web Service e ***_W3WP (onde *** é nome da instância de IIS)  do Performance Monitor (perfmon).

Servidor de Aplicação

monit03_03

Java e .NET são as tecnologias mais populares para desenvolvimento de aplicações corporativas, portanto trabalharemos mais sobre a ótica delas, mas o conceito se aplica bem a (quase) qualquer linguagem de programação envolvida. Veja o que é interessante coletar e dê uma estudada em que métrica ou coletor se aplica à essa necessidade para a tecnologia que você está utilizando.

Java

Existem diversos servidores de aplicação e containers Java, exemplos são o TomCat, JBoss, WebSphere e Weblogic. Uma coisa que todos eles têm em comum, é o Java rodando por debaixo dos panos e esse Java tem que atender às necessidades da especificação da linguagem.

No que tange à linguagem, precisamos ter visibilidade do Garbage Collector, que é o responsável pela limpeza da memória Heap, onde são alocados os objetos. Usualmente, as informações de quantidade de execuções, eficiência e overhead não são apresentadas pelos app servers, portanto é preciso adicionar alguns parâmetros de inicialização da JVM para fazê-los gerar esses dados. Criei uma tabelinha com as JVMs mais comuns.

Dê sempre uma lida na documentação da JVM para encontrar mais parâmetros e procure gerar os dados de GC em um arquivo separado do log da JVM, pois fica mais fácil para trabalhar com as ferramentas de apoio. Se for o caso trabalhe também com alguma forma de rotacionamento desses arquivos gerados, pois dessa forma evitamos o consumo desnecessário de espaço em disco, que eventualmente pode fazer a JVM “crashar”.

.NET

O .NET também tem os mesmos conceitos de GC, com diferença que, como toda solução Microsoft, tem suas métricas de desempenho coletadas através do PerfMon. O conjunto de contadores que trazem métricas performance do CLR, que é a tecnologia análoga à JVM do Java, iniciam com .NET CLR. Entre eles sugerimos:

Ainda dentro das métricas de .NET, é possível coletar informações dos providers de conexão com os banco de dados SQL Server e Oracle, que dispõem de um conjunto de contadores específicos para eles. Se sua aplicação necessitar de algum provider específico, provavelmente após instalá-lo um novo cojunto de contadores será criado.

Banco de Dados

monit03_04

As métricas internas de banco de dados são as mais complicadas de serem coletadas e analisadas, especialmente por conta também dos diferentes vendors de solução que existem no mercado. Para essa camada, falaremos mais de uma forma genérica, sem citar o nome da métrica ou contador específico.

A monitoração deve ser capaz de apontar as instruções SQL mais demoradas do ponto de vista de tempo de execução, consumo de CPU e quantidade de leituras/escritas feitas no disco. Essas métricas são importantes, pois dependendo do tipo de contenção que for encontrado na camada de banco de dados, as queries que precisam ser otimizadas podem ser diferentes.

Os banco de dados relacionais que existem no mercado utilizam estruturas de memória para guardar blocos de dados, instruções SQL recentemente utilizadas, planos de execução e coisas do tipo. Entender como está o comportamento dessas áreas de memória é importante para determinar se ele está conforme o esperado ou deve ser feito algum tuning para obter melhores resultados.

__

Muitas outras camadas podem existir no desenho da sua aplicação, como por exemplo, mensageria JMS, BRMS, ferramentas de ETL ou outras tecnologias. Nesse post vimos somente as mais comuns, mas dá pra ter uma ideia do tipo de informação que precisamos coletar quando estamos realizando um trabalho de performance.

Era isso! Se tiver alguma dúvida, não hesite em postar um comentário ou uma pergunta na nossa seção de Perguntas & Respostas.

Amplexos!

Leia Mais

bw01

Simulando a largura de banda com o JMeter

Quanto mais próximos de simular um cenário real mais os resultados do teste corresponderão a verdade. Muitas vezes, para simular completamente um cenários de produção é preciso limitar a largura de banda para saber como será o comportamento da aplicação com clientes conectados em uma velocidade mais baixa.

Pouca gente sabe, mas com o JMeter é possível simular essa redução da largura de banda. Isso é possível através de um parâmetro, que deve ser configurado no arquivo jmeter.properties, que está localizado em JMETER_HOME/bin.

A primeira coisa a ser feita é remover os símbolos de # da frente da linha para descomentar o parâmetro. Em seguida é preciso calcular o valor da sua largura de banda no equivalente a medida que é usada no parâmetro.

O cálculo é relativamente simples. O CPS significa caracter por segundo. Cada caracter tem 1 byte. Cada byte tem 8 bits. Então, para simular uma largura de banda de 256kbps a fórmula ficaria assim:

(256 * 1024) / 8

Quando for colocar o resultado dessa matemática no arquivo de parâmetros, o seu arquivo ficará parecido com o trecho abaixo.

# Define characters per second > 0 to emulate slow connections
httpclient.socket.http.cps=32768
httpclient.socket.https.cps=32768

Atenção! Um ponto importante é que essa alteração só funciona se os HTTP Samplers foram do tipo HttpClient. Qualquer coisa além disso, não é garantia de bom funcionamento.

Era isso! Se você também tiver alguma dica para o JMeter é só mandar para a gente através do formulário de contato que nós publicamos e damos os devidos créditos a você.

Amplexos!

Leia Mais

Monitoração

Monitoração – Parte II: Quais métricas coletar?

Boas!

Na Parte I (Olhando para mais que simples logs) dessa série sobre a Monitoração falamos da importância de realizar uma monitoração eficiente durante a execução do teste de desempenho e de classificarmos as métricas para facilitar seu entendimento e a transformação de um dado que é puramente técnico em algo mais inteligível para um usuário/cliente que não é de TI.

Como vimos no post anterior há uma “classificação” de métricas entre Infraestrutura (ou hardware), Sistema e Negócio. As duas primeiras estão mais próximas do nosso dia-a-dia e se aplicam para 99% dos teste de desempenho que forem executados e dependem mais da tecnologia que está sendo utilizada. As métricas de negócio estão ligadas diretamente ao que a aplicação faz e cada teste terá seu conjunto de métricas aplicáveis.

Nesse segundo post da série vamos falar do nível mais básico, que é a monitoração de infraestrutura (ou hardware). Comentaremos sobre algumas métricas que são coringas e existem na maior parte dos sistemas operacionais. Pode haver uma pequena variação de nome entre elas, mas o conceito permanece o mesmo. Quando aplicável, falarei um pouco dos thresholds que podem caracterizar um problema.

[box title=”Thresholds” icon=”info”]Para equalizar conhecimento: thresholds (em sua tradução literal, limiares) são os limites saudáveis de referência para um ambiente em que podemos encontrar as métricas (ou contadores). Um contador com valores muito divergentes dos considerados saudáveis *pode* caracterizar um problema.[/box]

Que venham as métricas!

Vou colocar uma tabela com as métricas que acho que são importante coletarmos durante os testes de performance para identificar os pontos de contenção. Depois da tabela tem um breve comentário sobre os grupos e como alguns deles devem ser interpretados para considerarmos um problema de desempenho.


[trow] [tcell_heading]Grupo[/tcell_heading] [tcell_heading]Nome[/tcell_heading] [tcell_heading]Alerta[/tcell_heading] [tcell_heading]Crítico[/tcell_heading] [/trow] [trow_alt] [tcell]CPU[/tcell] [tcell]Context Switches[/tcell] [tcell][/tcell] [tcell][/tcell] [/trow_alt] [trow] [tcell]CPU[/tcell] [tcell]Utilização de CPU[/tcell] [tcell]70%[/tcell] [tcell]90%[/tcell] [/trow] [trow_alt] [tcell]CPU[/tcell] [tcell]Run Queue Length[/tcell] [tcell][/tcell] [tcell](2 * # cores) + 1[/tcell] [/trow_alt]

[trow] [tcell]CPU[/tcell] [tcell]Utilização de CPU por processo do SO[/tcell] [tcell][/tcell] [tcell][/tcell] [/trow] [trow_alt] [tcell]Memória[/tcell] [tcell]Utilização de Memória[/tcell] [tcell][/tcell] [tcell]95%[/tcell] [/trow_alt] [trow] [tcell]Memória[/tcell] [tcell]Paginação (pages/in e pages/out)[/tcell] [tcell][/tcell] [tcell][/tcell] [/trow] [trow_alt] [tcell]Disco[/tcell] [tcell]Utilização de Partição[/tcell] [tcell]80%[/tcell] [tcell]95%[/tcell] [/trow_alt] [trow] [tcell]Disco[/tcell] [tcell]Tempo Médio de Transferência[/tcell] [tcell]10 ms[/tcell] [tcell]20 ms[/tcell] [/trow] [trow_alt] [tcell]Disco[/tcell] [tcell]Avg. Disk Queue Length[/tcell] [tcell][/tcell] [tcell][/tcell] [/trow_alt] [trow] [tcell]Rede[/tcell] [tcell]Utilização de Bandwidth[/tcell] [tcell][/tcell] [tcell]75%[/tcell] [/trow] [trow_alt] [tcell]Rede[/tcell] [tcell]Latência[/tcell] [tcell][/tcell] [tcell][/tcell] [/trow_alt] [trow] [tcell]Rede[/tcell] [tcell]Bytes in/out[/tcell] [tcell][/tcell] [tcell][/tcell] [/trow] [trow_alt] [tcell]Rede[/tcell] [tcell]Erros in/out[/tcell] [tcell][/tcell] [tcell][/tcell] [/trow_alt] [trow] [tcell]Rede[/tcell] [tcell]Descartes de pacotes in/out[/tcell] [tcell][/tcell] [tcell][/tcell] [/trow]

Vamos aos comentários!

Primeiro os referentes à CPU. A utilização de CPU é importante, todos sabemos, mas além disso métricas como a Fila de Processos (Run Queue) nos ajudam a mostrar o quanto que nossos recursos estão saturados. A existência de uma fila acima dos limites mostra que os processadores estão sendo utilizados e que existem processos esperando por eles. Os Context Switches vão nos ajudar a entender se nosso ambiente está com muitas threads e a troca de contexto entre elas está gastando mais recursos do que o processamento em si.

A Memória é um caso a parte. Utilizar toda a memória disponível não chega a ser um problema. Começamos a ter impactos de performance se a quantidade de paginações começam a acontecer, por isso é importante ficar de olho nesses contadores. Um outro ponto interessante é que, em sistemas Unix, o SO aloca parte da memória para cache de filesytem, portanto não se assuste se a utilização estiver bem próxima de 100%, foque na paginação e está tudo certo.

Em máquinas que rodam processos que são intensivos de acesso a disco, os contadores de tempo médio de transferência, que é o tempo que leva alguma operação com o disco (leitura ou escrita), e fila de acesso ao disco são muito importantes. Especialmente para bancos de dados, espera-se que o tempo de acesso à disco seja inferior a 10ms.

O último grupo de contadores é de rede. Com eles a gente pode identificar problemas de comunicação e descarte de pacotes entre os servidores que fazem parte da arquitetura da aplicação. A utilização de banda é importante ser mantida abaixo do limite estabelecido, pois é conhecido que a tecnologia ethernet começa a apresentar problemas quando chega próximo de 80% de uso.

Ferramentas

Monitoração

Beleza, já temos as métricas e sabemos exatamente o que coletar, mas que ferramentas eu vou utilizar? A resposta depende de seu SO e de quanto você ou sua empresa estão dispostos a gastar por alguma ferramenta. O importante é saber que existem opções open sources, gratuitas e proprietárias para fazer esse trabalho. Comentarei somente essas gratuitas, ok?

Para os servidores Windows, já existe uma opção nativa do sistema operacional, que é o PerfMon – Performance Monitor. Nele é possível coletar uma boa parte (se não todas) das métricas que sugerimos nesse artigo e seu resultado pode ser salvo em formato CSV para uma posterior avaliação.

Em servidores Unix/Linux eu gosto de trabalhar com o NMON, pois coleta todas as informações e as consolida em um único arquivo, que pode ser facilmente tratado com o NMON Analyzer e já gera todos os gráficos que você precisa para visualizar mais claramente os dados.

Uma segunda opção, que também pode ser usada em diversas plataformas UNIX/Linux é o SAR. Seus dados podem ser processados com o kSAR, uma ferramentinha em Java que gera os gráficos necessários para as análises.

__

Bem, é isso que temos para hoje? Se você achou interessante, compartilhe e poste um comentário. Se você tem outras sugestões e métricas poste um comentário e entre na discussão.

Leia Mais

monit03

Monitoração – Parte I: Olhando para mais que simples logs

[box title=”Disclaimer” icon=”info”]Esse conteúdo está longe de ser algum material super profundo e com validade acadêmica de uma Stanford University. Muito do que estou escrevendo aqui é mais baseado na minha experiência de trabalho e o que consegui coletar com outros excelentes profissionais com que trabalhei.[/box]

Quando estamos executando testes de desempenho nas aplicações, a primeira resposta que temos que fornecer para o cliente é qual a capacidade de atendimento da aplicação, seja qual for a medida de negócio que seja usada para representá-la (transações por segundo, quantidade de usuários simultâneos…). O problema é que essa informação vem sempre acompanhada de outra pergunta: “Mas por que?“.

Quando recebemos essa pergunta (nesse contexto) o que está nas entrelinhas é, na verdade, “onde está o gargalo da minha aplicação?“.

Muitas vezes para responder essa pergunta são necessários mais dados para serem analisados e usualmente esses dados não são extraídos unicamente dos logs de teste que o JMeter gera para nós. Essas informações são oriundas dos próprios servidores e aplicativos onde a aplicação está disponibilizada e isso independe da linguagem de programação em que foi desenvolvida e quais tecnologias fazem parte de seu desenho (application server, banco de dados, servidor de mensageria…).

Por isso tive essa ideia de criar uma série de posta falando exclusivamente de monitoração. No primeiro post desse assunto eu iria abordar algumas métricas básicas que devem ser coletadas quando estamos executando os testes de desempenho, mas resolvi dar um passo atrás e primeiro soltar um post mais teórico, onde a gente vê os tipos de monitoração e, em uma segunda etapa, mergulhamos na parte mais prática do negócio.

Tipos de monitoração

Essas são as categorias que eu costumo classificar as métricas que tento coletar quando estou executando um teste de desempenho.

Monitoração de Infraestrutura

monit05

Essa tipo de monitoração é a mais básica que existe, mas não é comum que ela seja negligenciada, especialmente quando estamos falando de empresas que focaram no mais no desenvolvimento de suas aplicações do que na sustentação delas no seu dia-a-dia.

Quando falamos de monitoração de infraestrutura descemos o nível de abstração para um dos mais baixos que existem no mundo de TI da atualidade. Basicamente todos as máquinas que temos hoje, sejam elas servidores, smartphones, appliances de rede, ou qualquer outra coisa precisam de uma CPU para realizar o processamento das operações ou uma memória volátil para armazenamento das informações ou mesmo um disco rígido para persistir os dados.

Monitorar essas informações é de suma importância para identificar, se durante o teste de desempenho, a contenção que foi encontrada na aplicação é porque o servidor onde ela está rodando ficou com 100% de CPU ou começou a realizar muita paginação e por isso começou a ficar cada vez mais lenta.

Monitoração de Sistema (ou Sistêmica)

OK! Essa etapa de monitoração é como se fosse um segundo nível da informação levantada durante a monitoração de infraestrutura. Há nesse nível uma abstração maior dos bits e bytes que compõem as aplicações e começasse a se pensar um pouco mais nos itens fundamentais para aplicação funcionar corretamente e na experiência de uso da aplicação para o usuário.

Uma aplicação Java desenvolvida para web, por exemplo, deve rodar sobre uma JVM (Java Virtual Machine). Nesse exemplo, a monitoração sistêmica irá coletar métricas específicas dessa JVM, como quantidade de threads que estão sendo utilizadas, quantos de ciclos de GC aconteceram ou a quantidade de mensagens na fila JMS, são alguns exemplos.

No que tange a experiência do usuário, informações como a quantidade de requisições que aplicação foi capaz de atender simultaneamente e o tempo de resposta de cada uma delas e o código de resposta da aplicação são informações importantes para entender o funcionamento do sistema e como o usuário final se sente ao usá-lo.

Costumo também enquadrar nesta categoria a monitoração dos logs de erro que a aplicação/sistema ou tecnologia (banco de dados, servidor de aplicação) na busca por exceções não tratadas ou erros de infraestrutura, como mal comportamento do banco de dados.

Monitoração de Negócio

monit04

Quando falamos de abstração de informação esse é um dos níveis mais elevados. Usualmente esse nível é o mais utilizado pelos usuários, pois as métricas que acabam surgindo nesse nível estão muito mais próximas do dia-a-dia dele e, por consequência, mais distantes do nosso.

Para quem trabalha em uma seguradora, por exemplo, é “fácil” falar da quantidade de propostas que foram inseridas no sistema no dia, mas transformar essa informação em algo mais “computacional” é mais complicado. Por quantas telas da aplicação o usuário tem que passar para inserir uma proposta? Quais os principais tipos de propostas emitidas? Quantas propostas viram de fato um contrato? Quantos registros no banco de dados são gerados para cada proposta/contrato emitido?

Responder as perguntas relacionadas ao negócio são importantes quando estamos conversando com a área de negócio, para quem geralmente os sistemas são desenvolvidos, mas o leque de opções que podem aparecer é praticamente infinito e depende do business em que a aplicação está inserida.

Lembre-se, para o usuário final faz sentido falar em propostas por dia e não requisições por minuto ou percentual de utilização de CPU.

Pronto! Acabou a teoria! Prometo que o próximo post sobre o assunto monitoração terá mais informações práticas para a execução de um teste de performance descente e como deixar o cliente de boca aberta com a quantidade de informações sobre a aplicação/ambiente dele está sendo apresentada.

Amplexos!

Leia Mais

u03

Criando um script de testes com upload de arquivo

[box title=”Disclaimer” icon=”info”]Esse é um post que foi baseado em uma das perguntas que tivemos em nossa seção de Perguntas & Respostas. Então se você tiver alguma dúvida, passe por lá e veja se alguém já não passou por esse mesmo problema.[/box]

Fazer uploads é um requisito recorrente para os testes de carga, portanto é importante saber como representar esse cenários nos scripts de teste. Para realizar esse case, peguei pela internet e dei uma customizada em uma aplicação web em Java, para ser disponibilizado em um servidor de aplicação como o Tomcat. O pacote para download está disponível no final desse artigo.

Então vamos lá! O primeiro passo é entender como funciona a aplicação e seu fluxo de chamadas HTTP. No nosso caso, a aplicação que vamos testar é basicamente composta de um único formulário onde é possível selecionar um arquivo para upload [1]. Esse arquivo então é enviado para o servidor e, depois que a requisição for atendida, uma mensagem de “Upload realizado com sucesso!” é apresentada.[2]

Agora que a gente já conhece a aplicação, precisamos montar o script que simule esse fluxo. Para isso, precisaremos de duas requisições. A primeira, que apresenta o formulário para seleção do arquivo; e a segunda que envia o arquivo e, após ser processado, apresenta a mensagem de sucesso.

Essas duas requisições estão apresentadas na árvore de elementos da imagem abaixo e são do tipo HTTP Sampler, o sampler mais utilizando no JMeter quando estamos falando de testes de desempenho em aplicações Web. Na mesma árvore também pode ser visto um outro componente, que é do tipo Listener. É o View Results Tree. Ele será responsável por mostrar as respostas de cada um dos samplers de envio de requisições.

O primeiro sampler é bastante simples e faz apenas uma requisição HTTP do tipo GET para a URL onde está disponibilizado o formulário de envio de arquivo. Para esse componente não há nenhum mistério de configuração, apenas tive que me preocupar com os campos Server Name, Port e Path. Esse sampler é responsável pela primeira parte [1] do fluxo da aplicação que foi citado acima.

u01e

É na segunda requisição que a mágica acontece! Ela também é um HTTP Sampler, como pôde ser visto na imagem acima, mas ela tem um elemento “especial”. Além de apontar para uma URL diferente, como está sendo ressaltado pela seta em vermelho na imagem abaixo. O tipo de requisição é diferente. Ela é do tipo POST.

A parte dassa diferença, no envio de arquivos através do JMeter, para a maioria das aplicações é fundamental que duas informações sejam preenchidas corretamente. A primeira delas é o checkboxUse multipart/form-data for POST” que precisa estar marcado (selecionado ou ticado. Como preferir!), como apresentado na imagem abaixo.

A segunda é o arquivo em si. O arquivo ou lista de arquivos deve estar com seu caminho completo (ou alguma variável do JMeter que aponte diretamente para ele) dentro da tabela “Send Files With Request“. Para cada arquivo deve ter uma linha nessa tabela, onde além do caminho para o arquivo, deve também estar preenchida a coluna “Parameter Name” onde deve ser referenciada a variável POST que o arquivo está representando. No caso da minha aplicação, o nome da variável é uploadFile.

u02e

Daí é só executar o teste e acompanhar a página de envio realizado com sucesso! 

Apesar das etapas serem simples, é importante ficar de olho no checkbox “Use multipart/form-data for POST”. Eventualmente ela é caso de dor de cabeça quando se está fazendo uploads de arquivo com o JMeter.

Amplexos!

Arquivos para Download

Leia Mais

tt01

O que é o think time? Por que ele é importante?

Geralmente quem trabalha e/ou lida com testes de performance no dia-a-dia acaba dando de cara com um conceito muito comum que é o think time, também referenciado como tempo de pensar (feio, hein?!).

Colocando de uma maneira bem simples, o think time é o tempo que o usuário passa interagindo com a aplicação, mas sem gerar requisições para o servidor, como por exemplo lendo um texto que está sendo exibido na tela ou preenchendo um formulário de cadastro.

[box color=”orange” title=”Importante!” icon=”info”]Um ponto muito importante devemos considerar sobre o think time é que é uma medida que deve ser levada em consideração quando estamos testando aplicações que são usadas por operadores humanos. Se estivermos testando aplicações onde há uma interação do tipo sistema-sistema, como por exemplo web services, não há necessidade de considerá-lo.[/box]

E será que o JMeter tá preparado para trabalhar com o think time?

É para simular a existência desse think time que está embutido no JMeter um conjunto de componentes chamados timers, ou temporizadores. Esse componentes

tt02

No futuro faremos um post dedicados a estes componentes, mas por enquanto, é importante saber que eles existem e que podemos contar com eles quando queremos simular o importantíssimo think time, nos nossos testes.

Um dos timers que é bastante usado é o Uniform Random Timer, onde podemos definir um offset mínimo e uma variação, para mais ou para menos.

Eu não usei o think time quando executei meus testes. E agora?

Calma! Sempre tem uma salvação. Você não colocou nenhum timer para simular o think time, mas se você souber qual seu valor, é possível considerá-lo quando estiver fazendo a análise dos resultados.

Se durante a execução dos seus teste você não usou o think time, cada thread do JMeter não estava necessariamente simulando um usuário real da aplicação, neste caso chamamos essa thread de usuário virtual. A questão então é converter usuários virtuais em usuários reais. Para isso leve em consideração a fórmula abaixo.

RUsers = VUsers / (RTime / (RTime + TTime))

É isso? Valeu? Se tiver alguma dúvida é só postar um comentário ou uma pergunta na seção Perguntas e Respostas.

Leia Mais