Por que eu deveria testar a performance da minha API Arianze Izac #thedevconf

bom gente então Eh A ideia é a gente conversar um pouquinho hoje porque eu deveria testar a performance da minha ap E aí eh me apresentando né Eu sou Ariane Isac Eu trabalho na ctc ctc é uma consultoria mas tem também algumas soluções tem aí mais de 27 anos no no mercado eu sou alocada na na Elo a Elo a bandeira de cartões e sou apaixonada por idade de software por performance tô mais aí de H mais ou menos uns 14 anos na área com performance de 3 A 4 anos e é o universo que

a gente desbrava eí a cada desenvolvimento a cada projeto e alinhando algumas coisas aqui então assim quebrando algumas expectativas também então se vocês acharam que eu ia quebrar alguma aplicação aqui ou eu ia focar algum em uma ferramenta Essa não é a ideia a ideia é a gente ter aqui trabalhar com três pilares com o que quando e por e com esses Pilares independente da pi que você for trabalhar independente da empresa do projeto você consiga ali ter insumos para de fato identificar a necessidade do teste de performance dessa pi e subir com segurança pra

produção então e a gente tem um Plus aqui mostrar uma uma uma demo e nela vou tentar trazer insumos de dia a dia porque a gente vendo na teoria é fácil na hora de aplicar a gente tem algumas dúvidas ali cruciais e eu não sei como é que eu vou fazer com esse microfone bom falando de O quê é legal a gente ter clareza com relação O que são requisitos não funcionais e o que é teste de performance bom falando de O que são requisitos não funcionais que que é importante a gente entender pera aí

eles são os requisitos relacionados ao uso da aplicação então el eles não interferem diretamente no desenvolvimento do sistema e sem sempre que a gente vai desenvolver ali né uma uma API Pera aí que vai ficar difícil aqui que eu fic segurando Ai meu Deus que tá comendo meu tempo aqui acho que não não vai entrar po não então aqui que que é quando a gente começa né num projeto a gente tem muito foco no funcional né E quando a gente fala aqui de requisitos funcionais é importante a gente entender que ah é mais fácil por

quê a gente tá falando de regras de negócio de definição ali dos fluxos da pi O que que a pi deve fazer e quando a gente fala dos não funcionais ali ele tá mais ligado ao como né E aí é bem mais difícil da gente ver posso tentar E aí não tudo bem Vamos lá gente vai dar certo e aí então Eh além de ser mais difícil de prever eh a gente tá muito mais lincado ao comportamento da pi Mas o comportamento da pi é da forma que que ela vai ser consumida né então assim

a gente não sabe como o cliente a aplicação vai utilizar isso então a gente não sabe eh como ela vai ser usada como que ela vai se comportar se tiver um maior volume se ela tem integrações ou não apesar da gente falar integração é um é um outro fornecedor vamos falar assim que é responsável mas for pensar em fluxo ela pode nos afetar ali indiretamente é importante a gente entende essa questão de integração e de performance também o quanto aquilo vai nos afetar eh sempre fazendo a projeção ali pra produção eu troco Alô acho que

tá desligado tá não então beleza então Eh e outro ponto importante também né será que tem concorrência então assim quando fala de concorrência às vezes ali pensando no backstage eu posso ter uma ap que tá fazendo algum update em algum registro e ela pode concorrer com outros no teste funcional é muito difícil a gente conseguir identificar esse problema porque a gente tá trabalhando ali com pouco volume então a gente tendo esse essas questões já pensando no início do ciclo do desenvolvimento eh e vai ali nos direcionar melhor para até ali a arquitetura que a gente

vai projetar falando em teste de performance assim tentando ser bem breve nessa parte então ele vai ser um teste não funcional e ele vai ter por objetivo aqui medir o desempenho da aplicação bem eh implícito esse ponto né a capacidade aqui também da aplicação então assim quanto a minha api vai suportar ali de volume e ali eu suportar talvez é entender dentro do meu contexto de negócio o quanto ali ela tem que performar com um maior volume quão confiável isso é né e ali é questões de disponibilidade também então se eu tô trabalhando com uma

carga muito grande pode ser ali que não aguente E aí se reiniciar Qual que é o problema dela ficar um período indisponível a gente pode ter casos ali que segundos de indisponibilidade pode gerar ali prejuízos de milhões então ali tem as questões também com com relação ao risco envolvido né quando a gente fala de disponibilidade a gente já pensa também em de resiliência ah eu tô trabalhando com muito volume se não suportar caiu E aí ela consegue e ter mecanismos de recover e ter mecanismos ali de retry de forma ali que atenda o meu contexto

ela é escalável a ponto de eu aumentar ali a quantidade de máquinas e mesmo assim ali e manter o as métricas que eu preciso e quando a gente fala de performance é muito a gente falar de opa fazermos experimentações né né então ali eu entender Quais são os obstáculos relacionados ao desempenho e esses obstáculos eles podem estar relacionados a configurações e aí pode ser a configuração dentro ali da da api mas pode ser também configurações relacionadas a a questões de hardware e pode ser que né acontece né que seja um GAP de fato na AP

que a gente precisa tratar para que em produção a gente não vinha venha a ter problema e fazendo essas experimentações a gente consegue também entender Qual que é a necessidade de hardware que a gente vai precisar para trabalhar com aquele volume Ah então eu vou conseguir entender quanto de memória que eu preciso quanto de CPU eh eu vou entender o comportamento da minha aplicação então talvez ali sendo redundante mas mais para frisar mesmo questão de entender a capacidade e utilização de recursos ali então relacionados não só a memória CPU mas também às vezes a quanto

de log que eu tô projetando Será que o o espaço em disco ali vai ser suficiente e um outro ponto não menos importante é a gente ter clareza do alinhamento com todos os envolvidos e os envolvidos podem podem ser as pessoas mais técnicas Mas podem ser também poos pessoas de negócio então a gente tem que ter certeza que todo mundo tá falando a mesma língua Qual que é o objetivo por que que eu preciso ali testar a performance daquilo né Qual que é o contexto tanto contexto de negócio quanto o contexto técnico como que é

a arquitetura daquela API quais são os riscos envolvidos então dei o exemplo ali da de ficar segundos indisponível e ter perdas ali De Milhões eh qual que é a criticidade dessa pi que a gente tá trabalhando e é importante a gente ter clareza também com relação ao escopo o escopo tá relacionado a qual que vai ser a estratégia que eu vou aplicar para validar a performance para isso e o não escopo também é importante quando a gente fala de não escopo é o que a gente não vai tratar naquele momento Então vou tentar dar um

exemplo bem simples eu comentei das integrações pode que num teste de performance nem sempre a gente e também nem sempre é recomendável que a gente faça num ambiente produtivo a gente vai fazer num ambiente ali de homologação E se eu eu tenho uma integração com uma outra API de um terceiro um fornecedor Pode ser que ele não tenha um ambiente de homologação para validar performance se eu for fazer o teste Integrado de fato com ele eu vou derrubar o ambiente dele então pode ser que eu tenha ali como estratégia mocar aquela ponta e assumir que

eu vou olhar só de fato o meu ponto meu o meu foco da minha pi mas se eu for falar na hora de subir de fato paraa produção eu posso assumir o risco de de fato al ter algum problema e todo mundo tem que estar alinhado com isso E aí isso com com qu né a criticidade pode dizer se eu posso eh seguir esse caminho ou não e a gente ter definições também de critérios de aceite que são as métricas porque não vai fazer sentido validar a performance sem ter ali uma definição Ah qual que

é o as mais comuns ali né qual Qual que é o tempo de resposta que eu preciso alcançar ou qual que é o TR output ali a vazão né transações por segundo pode ser por minuto e aí vai depender de como é quando quando a gente fala de api geralmente é transações por segundo e adiantando um ponto que talvez vai ficar mais claro quando a gente mostrar aqui na prática é importante a gente entender que uma métrica sozinha nunca vai se falar por si só então às vezes eu vou ter que quando eu tiver analisando

aquilo fazer a junção entender do tempo de resposta e o TPS para chegar a conclusão se houve algum problema o que que aconteceu eu nunca vou olhar para uma só ver aqui vamos esquentando agora acho que uma dúvida muito comum é quando que que eu deveria testar performance né quando que faz sentido Então se a gente pensar assim ah eu já tenho uma API que eu sei que ela trabalha com volume e eu vou fazer alguma alteração alguma melhoria vou aduma idade cara então se você já sabe que trabalha com volume então talvez ali puxando

umas orelhas el a gente já deveria ter um teste de performance realizado nela Então faz sentido que eu refaça esse teste para garantir que o que eu tô inserindo não vai ter efeito colateral de performance uma coisa que é muito comum a gente fazer até algo que eu vivencio no dia a dia é a gente pensar nesse para esses casos Num asist to be então o ezis é a forma como me ap tá hoje então eu tenho ali De acordo com o que eu entendi ali do dos critérios da necessidade de negócio eu tenho um

baseline e eu vou fazer alguma alteração nela eu faço um tubi e eu eu garanto que o que que foi alterado não teve nenhum efeito colateral ou se dependendo do que for a alteração e já for ali esperado que pode sim de fato ter algum alguma alteração tenha um alinhamento do um time com relação ao que é aceitável qual talvez não seja o número do baseline mas a gente já sabe qual é o baseline Então até quo eu eu aceito para mim é faz sentido uma outro candidato a testar performance ah eu tô desenvolvendo uma

nova pi e eu já sei que vai ter Projeção de volume então Para eu não ter surpresas em produção é recomendável que eu valide o a performance disso ah eu tenho ali processamento com volume e eu sei que trabalha com janela então ali Ah tem alguma janela de fechamento ou tem ali algo específico que pode ter um prazo de aspiração para eu processar tudo aquilo então é interessante entender ah qual que é a projeção de volume Qual que é o tempo dessa janela então ali ele é um candidato a eu validar para garantir que dentro

do tempo previsto todo o processamento foi realizado Ah eu tenho concorrência seja ela de muitos usuários simultâneos então quando a gente fala de performance a gente fala de threads né ou usuários simultâneos ou eu tenho ali muitos requests simultaneamente então ah lembrando aquela questão do do update que eu posso ter ali em o mesmo registro se eu eh não não validar isso pode ser que eu tenha ali questões de lock ou deadlock que eu não só vou enxergar quando tiver em ambiente produtivo e Ah eu tenho alguma previsão já de aumento de acesso Então pensa

alguma promoção E aí seja que eh num num cenário que eu vou fazer algum cadastro ou algo que converta em Venda eu sei que eu vou ali ter um período que vai aumentar quero garantir que eu não tenha problema nesse período de aumento então é um forte candidato a testar performance e a gente pode ter questões também ah eu quero garantir ali que o out scaling que eu vou configurar ele tá funcionando corretamente ele tá com os percentuais ali eh adequados para que eu escale as máquinas e mantenha ali a as minhas métricas de acordo

com a necessidade de levantada PR negócio também é um candidato a a validar a performance e tudo isso o que que a gente leve em consideração sempre né criticidade riscos e contexto E aí entrando um pouco mais ali pro clímax de fato da ideia da da palestra né mais umas duas perguntas pra gente responder por que que eu teria problema em negligenciar os requisitos de performance né Talvez o negligenciar Pode Só um pouco forte né Essa palavra mas a ideia foi para para fazer de fato vocês refletirem mesmo com relação a Quais são os problemas

Quais são as consequências que a gente pode ter quando a gente deixa de lado os requisitos não funcionais né nesse caso aqui especificamente de performance eu enxergo dois pontos principais hoje que é a falta de direcionamento pro desenvolvimento e aí o que pode pode acarretar nisso né implementações erradas seja ela de arquitetura de codificação implementações incorretas também na modelagem de banco de dados E aí seja em queries onerosas seja ali na falta de criação de índex e algumas decisões erradas também de infraestrutur porque a gente não pensou Nessas questões a gente focou só na parte

funcional e a questão também de falta de visibilidade No Impacto do negócio talvez aqui é a gente pensar mais numa visão sistêmica mesmo ali num num ponta a ponta num como um todo quais riscos que eu podem estar envolvidos nisso né com relação ao cliente que vai consumir essa pi e a a a riscos relacionados à receita né meu minha pi fica indisponível que quais os os eh as consequências que pode ter para quem tá consumindo isso um alto tempo na da na resposta ali vão pensar em algo que é eu eu t Tô fazendo

uma compra eu desisto porque por conta do alto tempo ou é uma transação ali talvez mais no meu mundo eh de transação bancária E aí um alto tempo Será que a pessoa pode desistir da na conversão de venda eh e alta taxa de erro também quando eu tô trabalhando com muito volume e a a pi não aguenta a aplicação geral não aguenta ela vai retornar um erro Qual será o impacto disso eu eu tomar o erro pode pode me implicar na não conversão então ali essas questões eu não pensar Nessas questões eu posso ter ali

diante de produção esses impactos E aí agora indo pro foco né que é o que vocês querem saber aqui diante de tudo Talvez o que a gente já falou um pouco fica claro com relação ao porque que eu deveria ter tá a performance da minha pi né Então na verdade aqui eu separei em seis motivos então o primeiro primeiro seria a prevenção de problemas talvez esse é um dos mais importantes com relação a gente pensar em um bug em produção na verdade quanto mais tarde ali a gente identifica um bug mais caro ele é eu

costumo falar que o de performance ele não é tão trivial porque assim quando você identifica um problema de performance para quem vai analisar Às vezes pode ser que no seu contexto você tenha ferramentas ali APM que fique mais fácil você rastrear e entender exatamente ali o ponto do do código que é o o GAP no como um todo mas nem sempre é assim tão simples e até você identificar quando você for corrigir aquilo pode ter algum efeito colateral do funcional não é algo que é você consegue muitas vezes disp disponibilizar rapidamente em produção então ali

por por por essas questões e a gente pensar ali que eh eu ia falar problemático mas vamos falar assim mais delicado então considerando os riscos e criticidade talvez é muito interessante você pensar Nessas questões já em tempo de desenvolvimento então o segundo tá bem lincado com que a gente falou no item do do negligenciar que seria Ter um melhor direcionamento ali no desenvolvimento né da arquitetura principalmente às vezes parece que falando assim é não imagina que vão construir algo que a arquitetura não atenda mas cara quem quem nunca né já vi não foi só uma

vez não eh e aí é muito crítico porque é você pensar que você pode jogar o seu código todo fora quem Eh aí A questão não é só a empresa né é assim talvez até envolve ali uma uma frustração dos envolvidos no na no desenvolvimento daquilo eh a gente evita também retrabalhos E aí quando a fala de retrabalhos a gente linca muito ali a a custo somente né ali a perda financeira porque Ah eu vou ter que dispor eh horas ali para para corrigir aquilo mas pensa que o tempo que você tá corrigindo aquele ponto

que você poderia ter já pensado antes no início do desenvolvimento ali já projetado um teste para não acontecer esse problema em produção eh você poderia gastar com trabalhando numa melhoria ou até na construção de novas Apis e a gente pode ter a questão também aqui de zelar pela reputação da aplicação da api aqui que a gente tá falando né talvez quando fala de api a gente sabe que algo vai consumir ela né então pode ser alguma outra aplicação algum frontend mas ali eu posso estar linkado com uma exposição negativa daquilo em redes sociais Isso é

um problema pro eu pensando eu como fornecedor né pro meu cliente e eu vai trazer uma experiência ruim pro usuário que tá utilizando aquilo e talvez o quatro tá bem lincado com o quinto de não causar danos aos clientes e os usuários né então ali e os danos pode pode ser a as questões de do tempo ali de não conversão né E pode ser também das indisponibilidades e a gente pode ter questões legais ali envolvidas também né E às vezes a gente pensa que só é um problema diretamente do cliente que tá usando não a

gente pode ter questões de pensando nós como os fornecedores da nossa Api para algum cliente que vai usar a gente tem um contrato já casos de contratos que eh tá fechado um sla Então você tá falando que você vai cumprir ehem todos os um percentual de request x tempo e x TPS então ali pode trazer problemas ali para pra empresa não pensar Nessas questões agora tentando fazer um link aqui na prática né vai ser um handson jemer Tem gente que fala mal do J metter Mas eu particularmente eu gosto go bastante não vou negar por

quê JM é uma ferramenta open source ela é em Java e o que que eu acho interessante nela ela ela suporta vários protocolos então se eu trabalho em um lugar que eu tô pensando que talvez não é só a pi que eu vou focar se eu trabalho com eh um e-commerce tem algo relacionado a web ou eu trabalho com mensageria eu queria validar as questões ali de eh eu mandar mensagens com o cafca por exemplo você consegue implementar e ali então ele suporta vários protocolos ele suporta também ali conexões eh com eh banco de dados

e você consegue implementar algumas coisas também dentro dele então eu gosto bastante acho que ele atende vários contextos diferentes e é open source E aí que que eu queria mostrar nesse rzone para vocês talvez trazer links ali para pensar na prática o que pode ser um problema porque você pensar hoje já eu tenho uma uma ferramenta ali eh para eu aplicar o teste performance na minha pi você vai gogar e é muito fácil você achar informação o problema é quando você olhar pro seu contexto e falar e aí agora eu preciso aplicar vai começar a

ter dúvidas com relação a como eu monto script Como faz sentido Ah mas se eu tenho que chegar em tal tempo de resposta ou tal TPS como eu monto isso será que faz sentido eu contemplar todas as apis Será que a massa de dado pode ser um vilão ali para mim no momento de montar tá e como eu estruturo de acordo com a necessidade de negócios então eu vou tentar trazer alguns pontos para que nesse contexto bem simples vocês tentem trazer pro contexto de vocês e aí vai começar a fazer sentido então eu vou usar

um fake stor api bem basicão mesmo e aí assim é bem simples é mais para pegar ideia então assim não construir nada já existe e essa e ess e esse exemplo não não faz muita coisa não mas vamos pensar que eh geralmente você vai ter um sweger e esse swager ele vai ter uma uma um conjunto ali de e apis e geralmente a gente sempre tem lá uma ap que faz um insert tem uma consulta pode ser que tem alguma que faz um update e um delite então tentando trazer para negócio pode ser que não

faça sentido você testar a performance de todas as apis que estão no sweger que que vai ser o pulo do gato a conversa com com o time ali com relação à parte de negócio de como vai ser e do entendimento técnico também você selecionar pensando sempre em como vai ser utilizado em produção e quando você pensa em em criar o teste performance não só ali você pensa sempre ah como que vai ser usado em produção mas como também são os dados que vão ser usados em produção para que você que o seu teste te mostre

os possíveis problemas que você pode ter lá na frente então quando eu falo de api dessa forma é que eu já vou mostrar no jemer Pode ser que pro meu cenário faça mais sentido e na questão de volume eu ter uma concentração nas consultas então ah na parte do de uma API que tem lá um um get beleza só que quando eu tenho essa pi que faz a consulta eu tenho vários parâmetros E aí como que ela vai ser utilizada porque pode ser que eu foque o meu teste com algum determinado conjunto de parâmetros que

eu deixe para trás um ponto ali do código que de fato pode ser um GAP e é a forma que vai ser usada em produção então sempre ali entender de fato Como é o meu cenário de produção para eu trazer isso pro teste para eu tentar ser mais assertivo então pensa que ah nesse nesse scenário que eu tô mostrando aqui na verdade eu tenho a eu posso ter algum momento que faz sentido eu vou ter um pico de de de uma API que faz um insert e depois eu depois que inser ele vai ter a

consulta e pode ser que não pode ser que eu já tenho uma determinada massa lá e que ela é feita ali a forma que ela foi injetada em um primeiro momento não é crítico com relação a tempo mas a parte da consulta é e eu posso ter uma determinada consulta que ela não passa nenhum parâmetro então aqui nesse exemplo que ele faz uma inserção de produto eu quero consultar todos e eu posso ter uma consulta por ID então aqui para não ficar tão confuso eu vou dar uma planada rapidinho no jmeter então assim aqui ó

quando você abre ele ele tem uma parte de plano aqui de de teste mas nosso foco maior aqui para vocês entenderem ele tem grupos de usuário e o que que vão ser esses grupos de usuário ele vai determinar na sua construção a quantidade de trads que você vai trabalhar eu gosto ele tem bastante plugins também e eu gosto bastante desse concurrency trad group Então nesse concurrency trad de grupo que é o que a gente vai ver eu posso determinar aqui a quantidade total de trads ou usuários simultâneos que eu vou trabalhar e a quantidade de

eh steps que eu quero esse steps aqui é o Ramp up então assim quando eu tô validando a performance eu não coloquei aqui mas tem alguns tipos de teste performance que a gente aplica de acordo com cada contexto como não era o foco eh Decidi não não colocar mas o que que é importante a gente entender aqui nem sempre vai fazer sentido que eu teste volume já mandando a minha carga máxima porque não vai ser dessa forma também em produção e até para que eu consiga enxergar o momento de ruptura que que é o momento

de ruptura que a gente costuma dizer quando ali eh a o processamento começou a fugir ali da do esperado Ficou ali numa curva diferente do que a gente queria ou seja ou caiu a aplicação ou o tempo de resposta começou a subir muito eu consigo entender mais ou menos ali a quantidade de carga que isso aconteceu o problema eh e aqui eu consigo determinar a quantidade de tempo que vai subir essa carga e eu consigo determinar a quantidade aqui de tempo que vai rodar na carga máxima Então até trazendo exemplo geralmente de como eu aplico

eh antes de você validar a performance da pi você tem que garantir que no mínimo o funcional ela esteja eh respondendo Beleza o funcional superou essa ponta Beleza eu vou entender aqui no momento que eu tô montando o script eh como eu vou fazer a chamada Vou voltar aqui pro insert para lembrar de um ponto que muitas vezes a gente peca em massa de dados então ali às vezes eu entender porque quando eu faço com um só né então ah eu posso vir aqui se esse campo é que aqui ele já tá gerando o ID

automaticamente mas se eu passasse aqui uma ID ou se tivesse um conjunto aqui que fosse uma PK se eu não repeti se eu repetir isso pode ser um problema se eu tiver algum Campo aqui que é pré-cadastrado e talvez eu ten que pensar que eu mandar o mesmo Campo não vai fazer sentido eu tenho que pensar em variar essa massa para tentar trazer esse contexto de negócio pro meu teste Então a primeira dica é pensar na massa entender ali a talvez Qual que é o conjunto de informações que faz mais sentido pro meu contexto de

negócio e o que ali se eu não variar pode ser um problema e pensar Nas questões de eh quais parâmetros que faz mais sentido utilizar falando aqui de um outro ponto que é importante também quando você monta aqui a estrutura e aí talvez aqui eh não tá muito claro para quem não trabalha ali ainda com com performance e entender a quantas trads que eu utilizaria Qual que é a relação de trad com TPS então para tentar simplificar pense que tred a quantidade de usuários que eu vou trabalhar e o TPS vai ser a quantidade aqui

de transações por segundo que faz e o que vai determinar isso o tempo de resposta da minha api então algo que é bem acho que eu consigo mostrar o exemplo na hora que eu for mostrar o relatório para ficar mais claro esse ponto é é perigoso a gente confundir e a gente ali se tomar um caminho errado ali na na hora que eu tiver montando o meu script de de teste eh uma outra coisa que é importante também eu pensar e aí tentando fazer sempre o paralelo com relação a como é em produção a forma

que tá montada aqui hoje cada tred vai chamar aérie produto depois ela vai chamar aqui consulta do ponto de vista de TPS cada transação vai fazer ess essas essas duas esses dois requests em cada pi e pro TPS o que vai valer é a soma dos dois mas será que isso pra produção faz sentido é esse de fato o fluxo talvez pode ser que faça sentido que você quebre porque senão você vai deturpar ali a sua visão de de TPS eu gosto de sempre quebrar ali em um unitário então eu quebrei no unitário garanti ali

que funciona depois que eu garanti que funciona eu gosto de fazer um Smoke testing que qual que é a importância de fazer um Smoke testing eh antes de eu validar com volume maior Pode ser que eu identifique com um volume bem menor uma proporção ali até sem eu de fato escalar o meu ambiente para validar esse volume que aquele tempo já não tá atendendo isso na verdade tem alguns tipos de falhas comuns de performance eh que vão nos dar o termômetro ali De quanto é a projeção baseado no Smoke testing de que se tá dentro

do esperado ou não e de quanto ali A projeção que eu vou de fato trabalhar eu vou mostrar eu tô mostrando aqui a cara do jmeter mas no fundo ele a gente nunca usa a interface dele porque ele é uma aplicação e até já lembrando um ponto faça o que eu digo mas não faça o que eu faço a gente nunca roda um teste performance na nossa máquina local o ideal é que a gente tenha ali e um servidor próprio para isso e um mais robusto para que ele consiga ali de fato atender pensa que

é uma você tá usando também uma aplicação para validar sua aplicação então ali e você não pode deixar com que o que você tá injetando nela influenci de fato nos números que você quer ver e eu vou mostrar para vocês aqui a visão do injetor né então a visão do jmeter Mas que que outra coisa que é importante também esclarecer E você tem que ter a visão da sua ap então geralmente você vai ter ali e tem eh aplicações para monitorar isso que vão te dar uma visão melhor de de fato Quais são os tempos

de resposta quais ali são os traces com relação a à ap que você tá passando aqui via linha de comando dentro da pasta Onde tá o jitter eh você vai rodar o comando que é bem básico você vai passar de emitter aqui aqui a minha máquina é Windows no Linux é um pouquinho diferente mas a estrutura do comando é a mesma então você passa aqui o a o indicativo de que você tá querendo rodar eh sem interface gráfica você passa aqui o indicativo da onde está o o seu script a extensão do jmeter vai ser

jmx você pode passar também se você quer criar log disso e se você quer Já que no final da execução ele Gere um relatório então aqui basicamente vai ser D um enter ele vai executar e qual que é a dificuldade na verdade né não vai ser o enter ou que seja você colocar isso numa integração contínua para que te dê os feedbacks ali constantes com relação à performance o mais desafiador vai ser depois você analisar todos os dados quanto vai rodando aqui eu vou mostrar alguns exemplos para vocês eu vou mostrar o que eu rodeio

o Smoke E aí aqui ó só para voltar rapidinho o Smoke eu rodei em 5 minutos geralmente ele é rápido poucas trads e a bateria maior o que que é interessante a gente saber né É sempre bom a gente rodar um período maior para você conseguir sentir a degradação de hardware também que pode haver ali no no meio do processamento com volume constante ali eh na sua execução Então você aqui para que vocês consigam perceber o que eu tô falando essa é a cara do relatório que o jitter Gera então aqui ele me dá uma

visão Geral com relação às métricas então aqui ó ele dá média ele dá os percentis que os percentis seria que tem o 99 95 90 que é o percentual de de acordo com o tanto de requests que eu mandei que fica o tempo de resposta então ó às vezes de acordo com a criticidade talvez não faz sentido eu trabalhar com a média porque aqui a média ó vamos falar do a da consulta ela tá com 576 msos aqui ele sempre mostra em milisegundos mas no meu percentil 99 tá indicando que é 1.2 segundos então ali

se para mim num maior volume acima de 1 segundo for um problema talvez aqui eh o indicado é você investigar se é algo com relação a hardware que isso na verdade aqui que tá faltando que é o que como eu tô usando uma aplicação que eu não tenho domínio sobre isso né se é uma aplicação que eu tô de fato validando eu vou ter a visão ali das máquinas com relação ao consumo de CPU e de memória eh e aí você vai entender se isso é hardware ou se isso pode ser alguma coisa relacionado de

fato a sua ap E aí falando de entender melhor essas métricas né Ele tem alguns gráficos que por exemplo você consegue ver não sei se vai ficar muito Claro aí para vocês pera aí mas ele mostra aqui a a projeção em gráfico de qual foi da a da pi que insere e da pi consulta E aí lembra que eu falei que uma métrica sozinha não não não se fala não não traz muita informação pra gente sempre é uma junção então aqui a gente vê ó que tem um aumento de tempo tá vendo ele tem uma

outra visão que ele mostra pra gente os perenti E aí eu consigo ver que aqui ó quando aumentou o meu tempo de resposta de fato houve um pico aqui ó de um máximo de tempo que aqui nesse caso levou 21 segundos aqui também ele mostra em milissegundos E aí se eu for olhar o gráfico de TPS que são a quantidade de transações por segundo provavelmente houve uma queda aqui no momento que houve o pico então ali eu analisando essa bateria como um todo essas informações vão fazendo sentido e aqui ó quando eu trabalhei com pouca

carga que é a mesma mesma chamada no Smoke e no outro oficial aqui ó só para voltar para vocês ó quando ele roda via linha de comando ele mostra aqui a projeção de quantas tredes estão rodando e dá uma visão assim bem eh genérica que bem resumida da média de tempo máxima mínima e se deu algum erro né e o que que é importante ressaltar aqui ó tá vendo que aqui com pouco volume Então até 10 trads ele foi bem ó ele não deu nenhum erro Ó o meu percentual de erro tá zerado quando eu

rodei por um maior tempo e com uma maior massa que aqui eu rodei com até 30 treds aqui tem alguns relatórios ó que eu consigo ver a quantidade Total também de trads ó a quantidade aqui nesse teste principal ele foi até 30 e aí eu consigo ter uma visão também de acordo com que eu fui aumentando a quantidade de trad qual comportamento de tempo então assim ele tem várias visões mas frisando novamente aqui é só da visão do injetor eh o que eu queria mostrar para vocês aqui para ficar claro para vocês pensarem pro seu

dia a dia quando eu aumentei o volume eu tive aqui um percentual de erro quando tá na casa de 0,0 eu tô estourada agora que eu vi mas eu tô tô concluindo quando eu tô na casa de 0,0 alguma coisa ainda pode ser aceitável aqui o o o erro que deu ó Foi de Bad GAT aqui o ambiente não tava aguentando e Esse aqui é do próprio jitter Mas que que é importante ressaltar Pode ser que aqui se o seu percentual tá acima de um segundo pode de fato indicar aqui algum problema para você que

de fato a aplicação não tá aguentando essa carga então ali talvez vha a pena rever e performance para para ir fechando Então são experimentações e espero que tenha ficado Claro para vocês com relação aí os os porqu os entender a importância disso e deixar o convite também no final do mês vai ter um webinar e pela pela CTC pra gente entrar mais em detalhes com relação ao teste Performance em si com relação aos Skills que a gente precisa desenvolver para trabalhar com esse tipo de teste Então é isso muito obrigada eu espero que vocês testem

aí a performance da pi de vocês