falar um pouquinho agora sobre análises avançadas aqui usando o dotnet a gente tá desenvolvendo aqui nossa api já fou De Cash e tudo mais e aí vocês viram ali que eu comecei a fazer uns testes AB no swager clicando no botão e tudo mais é uma experiência que para tempo de desenvolvimento funciona só que muitos desenvolvedores aí muitas pessoas desenvolvedoras elas às vezes não TM ciência que performance escalabilidade e tudo mais isso é um critério de qualidade que a gente tem que levar em consideração também então um método que você desenvolva uma funcionalidade um endp parte do processo de desenvolvimento de software é também testar jogar uma carga ali naquele método que você tá desenvolvendo para você entender se ele tá performando bem ou não E aí você não precisa ficar fazendo isso manualmente existem ferramentas e uma delas aqui como sugestão que eu vou mostrar para vocês é o apast de emitter o apast de meter ele basicamente é um projeto ele é open source e ele é usado para load testing né teste de carga e tudo mais e ele ajuda a analisar a mensurar performance de serviço normalmente eu utilizo em serviços web web apis ou algum outro serviço que eu consiga eh enviar ou receber informações de endp então com o jmeter você consegue tanto trabalhar com requisições http https enviar ali todos o o o o post os Gets né tudo isso você consegue fazer E aí você consegue criar até um script de uma certa forma ali para você fazer um passo a passo de execução aqui o que a gente tem feito inclusive nas últimas aulas foi mostrar que né a gente consegue desenvolver ali as nossas apis colocando estratégia de cche em cima seja em Memory seja redis distribuído E aí a gente ficou testando manualmente então agora vamos fazer um pouquinho mais elaborado e eu vou mostrar PR vocês aqui o jitter o jmeter Pode pôr aí no seu ah navegador aí né no Google ou seja lá onde você pesquisa Procura pelo jmeter e você vai baixar o binário do jmeter então para você usar você baixou ele ali normalmente se você tá usando Windows aí ele vai ser um binário E aí você vai aqui ó na pastinha eu já baixei aqui eu tô usando Windows pastinha do jemer Bim e você vai encontrar o jer aqui no formato de jar né se a gente ver aqui você vai ver que tem um jar file aqui que é o ap de emitter tá ele não é instalável ele é um arquivo standalone aqui você consegue executá-lo E aí você vai abrir o gitter aqui na sua máquina ele vai ter essa interface Aqui tem bastante coisa se a gente fosse fazer uma aula aqui de J meter levaria horas e horas e horas porque tem diversos cenários Então vou trazer fundamentalmente uma opção que a gente pode ter para rodar o jer de uma forma forma tranquila E você coletar algumas métricas básicas que com certeza vão ajudar em projetos reais mesmo a primeira coisa que você vai fazer quando você inicia o jitter ele te dá aqui a opção de Um test plan ele vem vazio tá então você tem que começar a criar algumas coisas aqui primeira coisa que eu faço é criar um thread group então venho aqui add thread group ali embaixo thread users e aqui eu venho no thread group Então faz esse caminho aqui add thread users thread group tô usando um inglês aqui se você tiver usando o seu Windows em português vai est algo muito próximo disso esse trad group basicamente deixa eu adicionar aqui depois eu eu excluo eh ele vai dar algumas informações bastante relevantes tá que é por exemplo o o a quantidade de números de trads né que ele vai simular os usuários Então qual é a quantidade de número de usuários barra thread que você quer ter né Qual é o loop count que você vai ter ou seja aqui eu tô rodando um usuário rodando ele uma vez esse ramp period aqui o tempo de Ramp up é o tempo que você quer que ele demore em segundos para fazer o Ramp up dos Testes então se você colocar 10 segundos você vai dar start vai demorar 10 segundos ali ele vai começar a fazer esse Ramp up ali então o que que eu faço por padrão aqui eu vou fazendo os meus métodos né então vamos abrir o visual Studio rapidamente aqui vou imaginar que eu quero entender lá na minha classe do products Controller aqui a gente criou aquele método em Memory Cash né E aí de desenvolver esse cara aqui get products ele vai fazer o memory Cash que a gente fez nas últimas aulas E aí eu quero entender Qual a performance disso porque às vezes se eu fiz alguma estrutura de dados que não é muito conveniente enfim diversos cenários Mas enfim quero testar esse esse Controller aqui get products vou dar start nele aqui já então que que eu vou fazer aqui literalmente falando eu vou determinar node emitter aqui número de trads o número de lo counts então vamos comear assim vamos simular que seriam 100 usuários e ele vai fazer eh 100 vezes as requisições praticamente então 100 usuários ou 100 threads e ele vai fazer isso 100 vezes basicamente é multiplicar né 100 x 100 seria mais ou menos o número de requisição que você teria aí então vamos fazer aqui 10 vezes e 10 vezes pra gente começar isso aqui é o perfil do trad group é um grupo de trad que vai executar então Aqui é onde você especifica quantas vezes vai rodar se vai ter um Ramp up ali ou não e quant Qual é o número de usuários que você vai ter depois do trade group aqui ó até eu já tinha deixado um pronto aqui você vai adicionar add um sampler aqui e aí você vai colocar um http request porque nesse caso aqui a gente vai fazer um htp request Então esse é o caminho add sampler http request que a gente tem o Web api e é http aqui certo então a gente vai adicionar eh igual a esse aqui que eu tinha feito depois eu volto nele o que eu gosto de adicionar também é um summary group então a gente vem aqui depois em listener tá E aí a gente começa a colocar os sumários que esses sumários basicamente são os resultados do que vai tá acontecendo quando a gente for rodar aqui vocês vão ver e aqui você começa a adicionar né Você pode adicionar esse primeiro cara aqui ó View result 3 então só voltando aqui no caminho botão direito add listener né ele vai criar um listener praticamente para ficar o ouvindo as requisições da kttp que você está fazendo naquele outro elemento e aqui é só uma forma visual então a gente pode adicionar o View results 3 summary e se você quiser adicionar também o aggregate report aí você vai vendo que cada um desses aqui vai te dar um report diferente nesse caso deixa excluir esse aqui a gente já colocou um ali em cima já tinha colocado previamente mas htp request vamos pegar aqui as características que existem primeiro dentro dele o htp request eu vou ter algumas informações aqui para popular tá as informações são Qual é o protocolo então aqui ó https deix ficou um pouco pequeno https depois Qual o nome do Servidor né no caso aqui a gente tá rodando api localmente local host Qual é o número da porta você vai especificar aqui você vai falar qual que é o htp request você vai fazer get post etc etc e aqui é o pef então só se atente a isso aqui ó ao invés de colocar aqui local host dois pontos etc etc só o server name ou o seu IP lá do outro lado a porta aqui você vai ser um get um post um etc e o pef esse pef aqui corresponde ao mesmo pef que eu configurei lá na minha api então se você não tem certeza desse pef por algum motivo é só você ir lá no Swagger que nem a gente fez você poderia dar por exemplo um Execute aqui embaixo que o próprio Swagger aqui ó ele te mostra inclusive qual que é e o pf da execução aqui no request URL então o que a gente vai fazer lá no jmeter é isso coloca aqui o seu protocolo ali né você coloca aqui também o local host coloca a porta e esse aqui é aquele caminho que a gente colocou lá barra api bar products Ah beleza então vou deixar esse aqui rodando como se fosse servidor web E aí eu tenho o summary report ele vai me dando aqui algumas informações bastante relevante né então se eu colocar lá para ele rodar é 1000 vezes ele vai começar a encher isso aqui né 1000 vezes vezes de cima para baixo aqui vai colocando em request por request E aí você vai tendo aqui o número de requisições qual foi a média Qual foi o percentual de erro que você teve qual foi o trut que você teve cabides recebidos enviados média Então são diversas informações que vai ficar claro para você ali eh o tempo médio que tá demorando as suas aquisições obviamente fazendo essa esse exemplo local e depois fazendo isso no servidor RB num cloud da vida você vai ter parâmetros diferentes Tá eu vou passar uma estratégia depois legalzinha também que eu já fiz em produção acho que vale a pena fazer o View TRE também ele vai te fornecer e aqui o View results in table eu prefiro esse cara e é o que a gente vai usar para ver os resultados de uma forma mais específica Por quê eu consigo colocar aqui um file name ó e eu vou gerar um csv então o próprio jmeter vai exportar para mim o resultado daquele http request ou daquele conjunto de http request e vai salvar para mim nesse teste. csv e aí lá eu vou criar um relatorio Zinho bem rápido aqui no csv para vocês verem Então essa a configuração que vocês tem que fazer thread group http request Esse é o único mandatório e esses outros aqui é basicamente só para você ter eh relatórios tá e a gente vai usar esse relatório aqui de forma específica que é o table Beleza então vamos no trad group aqui eu vou colocar aqui 10 e 10 então ele vai ter 10 usuários com correntes fazendo 10 requisições ao mesmo tempo que é o loop count dele aqui em cima é o que a gente vai utilizar tá tem o os botões de de start E se eu precisasse Depois tem o botão de Stop aqui e depois quando eu quiser limpar o que tá aqui na exepção eu posso clicar nessas engrenagens para limpar porque aí ele limpa você vai ver né você faz 1 2 3 4 testes vai começar a juntar um monte de informação Ali você vai ficar um pouco perdido mas vamos rodar aqui primeiro Tá eu vou clicar aqui no View results in table e eu vou rodar aqui vou clicar aqui ó start sem pausa tá nesse momento ó já começou a rodar ele começou a rodar os htp request e já já ele vai acabar tá então ele foi muito rápido tá vendo ele fez 100 requisições no total então ele basicamente multiplicou 100 10 por 10 né 10 usuários 10 exões 10 x 10 100 E aí beleza e essa informação ela foi para nesse arquivo aqui então é daqui que eu quero extrair alguns insites tá então deixa eu copiar aqui eu vou eh executar esse arquivo aqui localmente ó ele vai abrir o Excel e ele vai trazer para mim algumas informações aqui que tá tudo bagunçado tá então basicamente tá tudo pago sal o que que eu vou fazer aqui eu vou pegar e eu vou em dados né Se tiver em português aí também ou inglês aqui data eu vou em texto para colunas e ele envia essas informações para mim tudo com vírgula então cada coluna dessa aqui eu tenho que arrumar essa indexação então eu vou colocar delimitado e vou vou pedir PR ele é colocar em colunas bonitinha aqui ó através de uma vírgula então ele vai tirar daquele modelo colado ali tudo junto e vai me dar as colunas certinhas tá aí eu vou em avançar e vou em concluir tá beleza isso aqui foi só o Excel básico mesmo mas o que que tem aqui ó tem as 100 requisições tá e você pode ver que a coluna que interessa aqui para mim nesse momento é lógico várias interessam né Por exemplo Qual foi o tempo de latência que você teve latência de rede e se teve idle time na sua conexão ou não bytes que foram enviados e se deu sucesso ou não aquela requisição né htp 200 por exemplo tipo de dados que foi enviado ali foi texto a gente estava trafegando Jason os response code Tá mas o que eu quero trazer aqui é essa coluna B que é a coluna de lapset tá esse laps aqui é quantos milissegundos demorou para rodar aquela requisição em particular Então a primeira requisição aqui ela demorou ó 133 segundos por quê Porque a nossa aplicação na primeira vez que ela rodou ali né voltando rápidamente aqui só para fazer sentido que eu quero explicar lembra-se que na primeira execução esse Cash ele não não vai existir então o que que ele tá fazendo ele tá vindo aqui nesse método get values from the BNC e tá pegando supostamente do banco de dados né Então a primeira vez que ele rodou ele teve um consumo maior ele demorou mais tempo para pegar a informação E aí você pode ver que depois na segunda Como já tava em cash ó os valores variaram e ficaram quase que irrisórios né até o momento aqui que ele chegou também a 60 Mas ó depois fica quase irrisório Então o que eu quero dizer com isso é aqui só olhando para esses dados a gente já consegue entender ah aqui eu não tinha Cash Putz aqui minha aplicação talvez estava construindo Cash ainda Ó nesses três primeiros Putz aqui já pegou o Cash necessário eu não me recordo corda de cabeça vamos olhar lá quanto tempo a gente deixou de Cash tá a gente deixou 15 segundos então basicamente durante 15 segundos aqui ele deveria estar rápido então a primeira interação não mas daqui para cá ele provavelmente tava com Cash lá eu acho que ele rodou tão rápido para falar a verdade ó tão rápido mas tão rápido que o Cash estava presente aí em quase toda essa execução porque foi muito rápido eu acho que rodou sem requisições eem muito menos de 15 segundos Então olha só já é uma primeira análise tá então beleza minha aplicação aqui que eu tô construindo ainda em tempo de desenvolvimento ela tá me trazendo essas informações e eu vou pegar isso aqui eu posso até brincar ó eu eu costumo fazer isso aqui quando eu vou apresentar isso pro time para fazer um review de código né eu seleciono a coluna B inteira dou inserir aqui ó e aí eu começo a trazer uns gráficos aqui esse elps aqui ele reflete Justamente a coluna né Então olha que interessante sem cche aqui a partir desse momento que eu pus o Cash Qual é a média né Qual é a média de resposta que eu tô tendo aqui é abaixo de 60 msos né então basicamente a minha aplicação cachada para um volume de 10 usuários fazendo 10 requisições por segundo tá levando ali uma média de 60 msos é mais ou menos essa leitura que a gente começa a fazer deixa eu tentar salvar isso aqui pra gente fazer um teste disso aqui depois deixa eu salvar aqui rapidamente eh senão ele vai salvar como Ah senão ele vai eh deixa deixar como teste teste dois aqui senão ele vai subscrever depois tá beleza deixa esse teste dois aqui e aí vamos fazer o seguinte Vamos alterar alguma coisa vamos ver se se eu mexer alguma coisa aqui na aplicação se vai piorar vamos fazer o seguinte tira esse cche aqui de de 15 vamos deixar um cche de três 3 segundos né vamos rodar então vamos ver se faz sentido deixar um Cash maior um Cash menor se tem alguma diferença de performance aqui ou não e aí a gente começa a medir desse jeito vai subir a aplicação de novo aí Lembrando que eu venho aqui né por padrão meu eu venho aqui eu dou um um Clean aqui ó ele limpa tudo para eu saber qual é a execução que rodou agora ou não tá eu tô fazendo isso aqui Manual também tá pessoal isso aqui você consegue jogar noira devops isso aqui você CONSEG u serviços em nuvem por exemplo o próprio Microsoft aure ele tem um servço que por baixo dele é umem rodando Tá então vamos executar de novo aqui com as mesmas características ó vamos rodar de novo aqui ele vai dar esse warning por eu deixei esse mesmo arquivo sempre então tem dados antigos lá foi por isso que eu S aquele test do. csv eu vou falar para ele fazer um overwriting tá porque eu já salvei o outro outro exemplo e eu vou fazendo isso tá eu vou criando arquivos eu pego pelo menos umas três quatro comparações tá aqui rodou tudo tá vendo status Ok vamos abrir o csv de novo e vamos ver se teve algum comportamento diferente do que teve previamente porque a gente mudou o código foi um mero ajuste de de cche ali né Mas pode ser que alguma coisa foi alterada vamos fazer de novo o mesmo procedimento dados texto para colunas avançar delimitado avançar imitar ele por vírgula Vamos dar um concluir deixa aqui um pouquinho mais bonitinho aqui vamos pegar o eleps vamos inserir e vamos inserir aqui um um texto aqui ó nosso gráfico de eleps de novo não me parece que surtiu tanta diferença deixa eu ver no outro arquivo se o Startup ali tava um pouquinho maior é piorou piorou porque ó aqui Esse é o primeiro arquivo aqui ele tava abaixo de 140 quando ele começou quando não tinha Cash e ficou numa média abaixo de 60 no segundo ele já Demorou mais uns 10 milos a mais e continuou depois de cachado abaixo de 40 só que mesmo assim eu acho que sem requisições nesse caso aí a gente já começa a fazer novas análise sem requisições nesse caso deve tá levando muito menos de 3 segundos por isso que esse parâmetro aqui ele continuou igual né ó ele continuou igual aqui porque todas essas execuções Ela deve ter levado muito menos de de 3 segundos né se a gente pegar uma soma aqui ó vamos fazer um soma isso aqui é milissegundos tá dando 701 701 msos realmente não deu nemum segundo tá vendo Então por esse motivo a gente mesmo alterando o nosso Cash isso Manteve o que dá para fazer agora como um teste final mas aí você tem que ficar comparando é aumentar a carga de usuários talvez então aqui ó eu vou lá no trad group de novo aí bom qual é o primeira foto a primeira foto é 10 usuários 10 aquisições simultâneas eu sei que tá rodando ali em menos de um segundo tá bom aí eu vou aumentar para 100 faz a mesma coisa essa é a dica vai sempre multiplicando por 10 eh começa o seu teste ali com 1000 usuários e com 1000 requisições por segundo por exemplo tira um SnapShot que nem a gente fez aqui depois você aumenta isso de 1000 para 10.
000 de 10. 000 para 100. 000 de 100.
