Introdução

Olá Pessoal, o objetivo desse post é explicar passo a passo, inclusive entregar scripts prontos para você configurar, medir e interpretar os contadores de desempenho de um servidor ou computador, para que você consiga identificar os seguintes pontos:

– Comportamento do sistema operacional quando sua aplicação está sendo executada;

– Quais os requisitos ideais de hardware, software e configuração para que sua aplicação funcione corretamente;

– Quando há lentidão, se essa lentidão está associada a um afunilamento de recursos e se esse afunilamento de recursos ocorre devido a pouco recurso, uso concorrente de outros aplicativos ou má gestão de recursos de sua própria aplicação.

– Quando ocorre um mal funcionamento de sua aplicação ou servidor, identificar se algum dos recursos estão sobrecarregados ocasionando esse mal funcionamento.

Medindo o Desempenho de Forma Automática

Atualmente contamos com ferramentas que automatizam o processo que explicarei abaixo. As ferramentas mais comuns são o System Center Operations Manager da Microsoft que consiste em você possuir um Servidor com o SCOM e Banco de Dados e nos Servidores ou Computadores que você tiver sua aplicação, ter o agente do SCOM instalado. Depois, implantar no Servidor do SCOM os Templates necessários e ativar as medições e coletar os dados. É uma ferramenta extremamente poderosa e fácil de utilizar. Indicada para empresas que possuem um Datacenter, CPD para gerir inclusive aplicativos de terceiros para avaliar seu comportamento. o SCOM consegue acompanhar medições de Serviços, Processos, Aplicativos Web (IIS e Apache) e Aplicativos JAVA.

Outra ferramenta que é uma evolução do System Center nesse sentido é o Microsoft Visual Studio Application Insights, que além de fazer as medições que comentei acima usando o mesmo principio do agente, também monitora diretamente a aplicação mas, voltado à falhas, exceções, uso de funcionalidades de sua aplicação pelo usuário, entre outros itens, sendo necessário instrumentar a aplicação via Visual Studio. Sua vantagem é que ela monitora aplicações in-loco, no cliente, em celulares, etc. Sendo que os dados ficam hospedados no Visual Studio Online.

Mas vale a pena ler esse artigo, pois antes de usar qualquer ferramenta, é importante entender o que medir e como interpretar cada medição, além de que muitas vezes você não terá tais ferramentas disponíveis para usar e as que indico nesse artigo são gratuitas e de fácil gerenciamento.

Contadores Base

– O que e quando medir. Entendendo os contadores

Em primeiro lugar esse post é específico para ambientes Windows, que é minha praia, mas existe muito material bom para outros sistemas operacionais como Linux, OSX, etc.

Há cinco áreas de recursos que podem causar afunilamentos e afetar o desempenho do servidor:

Essas áreas são: Disco Físico, Memória, Processo, CPU (processador) e Rede. Se qualquer um desses recursos for utilizado em excesso, o servidor ou o aplicativo poderá ficar muito lento ou até falhar.

Muito importante: Antes de sairmos enlouquecidos medindo o desempenho do disco e já dizendo que tem problema, ou de qualquer outro recurso, primeiro temos que entender um pouco sobre esse recurso. Por exemplo:

Atualmente um dos discos mais rápidos disponíveis no mercado são os discos SSD com barramento direto na placa como o da foto abaixo: (Sim isso é um disco)

Agora imagine que você coleta um dado e informa ao responsável pelo servidor que o problema é afunilamento do disco, sendo que o servidor possui um disco desse? A probabilidade de sua análise estar incorreta é de quase 100%. Realmente pode ocorrer um afunilamento, mas possivelmente um processo estar sendo executado de forma incorreta gerando esse afunilamento. E o pior, o administrador poderá vir com uma pergunta que normalmente deixa qualquer desenvolvedor ou analista de cabelo em pé, – OK, temos um afunilamento, preciso que você me diga quantos IOPS sua aplicação precisa… E aí meu amigo?

Por isso o ideal é termos o cuidado de analisarmos todos os contadores, fazer uma interpretação e ai sim conversar com o time de TI para ver se há algum problema nos recursos.

– Regras Básicas

É muito importante saber sobre:

* Desempenho máximo do hardware: Por exemplo, qual a taxa máxima de transferência de um disco rigido ou de um RAID configurado. O ideal é saber o modelo do hardware e consultar o manual do fabricante. Por exemplo, um aplicativo com o Microsoft SQL Server aceita no máximo uma leitura/escrita de no máximo 10ms, se passar disso ocasiona afunilamento. O ideal nesse caso, quando o hardware não suporta é ou trocar o mesmo por um de maior velocidade, ou montar volumes RAID ou JBOD para dar velocidade.

* Quais os contadores mais usados para medir o desempenho do servidor: Os mais utilizados são o disco, memória, processador, rede e o processo (aplicativo). Com esses contadores é possível entender onde está o afunilamento.

* Qual a associação entre esses contadores: Por exemplo, se estou tendo um afunilamento de disco causado por paginação do sistema operacional, significa que, a memória RAM “acabou” e o sistema está precisando escrever em disco para compensar a falta de recurso. Se o processador está com picos de 80%, e o disco e memória estão com uso dentro de sua normalidade, pode significar que está na hora de rever o processador e quantidade de cores utilizados.

– Algumas dicas

O ideal é medir esses contadores do servidor em si, pois com isso pode-se perceber nesses contadores que, algumas vezes seu processo (aplicativo) pode estar com problema de leitura e escrita em disco, mas observando o contador do disco percebe-se “folga”, ou seja, o aplicativo pode estar tento dificuldades em manipular arquivos e não que o problema seja o disco em si.

Seu aplicativo está usando todos os cores do processador corretamente, ou sua aplicação consegue balancear esse uso? Ou percebe-se que apenas um core dos 24 disponiveis no processador está sendo usado pelo seu aplicativo? Ou seu aplicativo ainda trabalha em modo 32 Bits?

Principais contadores

Para você ter uma medição assertiva, o ideal é medir o conjunto em geral do servidor ou computador que executa a aplicação e os contadores dos processos (os executáveis de sua aplicação e os executáveis adicionais como por exemplo o W3WP.EXE do Internet Information Services, quando sua aplicação é Web).

– Contadores do Servidor/Computador

Os contadores mais medidos e utilizados em um servidor são do Processador, Memória, Disco e as vezes rede. Sendo que dentre desses contadores há subcontadores específicos que você deve usar conforme sua necessidade.

Veja nesse artigo os subcontadores disponíveis e qual sua utilidade.

https://technet.microsoft.com/en-us/magazine/2008.08.pulse.aspx

– Contadores de seu Processo (Executável de sua Aplicação)

Você deverá medir individualmente os processos que constituem sua aplicação, sendo que desse processo, os contadores mais comuns são: Tempo de Processador, Handles ou Ponteiros, Memória.

* Tempo de Processador: Mede a porcentagem do tempo decorrido gasto pelo processador na execução de uma thread. Se a porcentagem for superior a 85%, o processador está sobrecarregado.

* Handles ou Ponteiros: Um objeto é uma estrutura de dados que representa um recurso do sistema, como um arquivo , linha, ou imagem gráfica. Um aplicativo não pode acessar diretamente objeto de dados ou o recurso do sistema que um objeto representa. Em vez disso, um aplicativo deve obter um identificador de objeto, que ele pode usar para examinar ou modificar o recurso do sistema . Cada identificador tem uma entrada em uma tabela mantido internamente. Essas entradas contêm os endereços dos recursos e os meios para identificar o tipo de recurso.

Ou seja, sua aplicação “abre” uma solicitação através de ponteiro (handle) ao sistema operacional para acessar um recurso, e depois de concluído, a mesma fecha. O que pode ocorrer é a abertura de inúmeros ponteiros sem a finalização após a consulta do recurso, gerando uma sobrecarga no sistema até a total indisponibilidade do mesmo.

Veja o contador abaixo do Perfmon, comparando com o Task Manager.

E qual o número ideal de Handles? Depende da aplicação, mas um comportamento visivel de que há algo errado é o acréscimo diário desse número, sempre mais aumentando que diminuindo, durante os dias. Mas em via de regra, qualquer processo que possuo mais de 10.000 identificadores abertos, possivelmente está mal projetado ou está ocorrendo um “vazamento” de identificadores e precisa ser avaliado pelo time de desenvolvimento.

Veja esse artigo: Pushing the Limits of Windows: Handles

Outra forma de identificar um possível vazamento de Handles é usar o Process Explorer da Microsoft e acompanhar a gestão dos identificadores, caso você perceba através do gráfico do Perfmon um aumento significativo de Handles.

No caso, habilitei a visualização do painel de Handles no Process Explorer e acompanhei o que um processo está usando, abrindo e fechando.

* Memory: Contador extremamente importante, pois trás para nós informações cruciais como o uso de memória pelo processo. Podemos identificar se o consumo está de acordo ao esperado, se há falta de memória ou algum vazamento por gerenciamento incorreto ou BUG.

Mas o quanto que é o suficiente que um processo pode usar? Quando sei que há vazamento de memória ou memory leak? Quanto de memória é suficiente para o Servidor ou Computador?

Primeiro você precisa entender o quanto que um processo de sua aplicação aloca para executar determinada atividade. Por exemplo, para minha aplicação processar um lote de 10 documentos de forma satisfatória o Processo A utiliza 2048 K de memória e o Processo B utiliza 1024 K. Depois de concluido o processamento, o processo libera a memória ou mantem o minimo de uso.

Nesse momento em que você mede a memória, você poderá avaliar os seguintes itens:

– Depois que o processo concluiu o uso de memória, ele libera a memória, mantém a memória, ou aloca mais e mais memória sem estar executando nenhum processamento?

– Depois que ele processou o lote de 10 documentos, quando ele processa mais um lote, ele aumenta significamente o uso da memória para o dobro? Ou seja, cada vez que ele processa um lote o processo duplica o uso de memória?

– A quantidade de memória usada pelo meu processo, é uma quantidade razoável onde irá funcionar em um ambiente padrão com servidores de 08 GB com seus outros processos concorrentes? Ou para que minha aplicação funcione, terei que disponibilizar uma quantidade considerável de memória para os meus processos, sendo aceitável isso para o mercado e cliente?

No Task Manager ou Gerenciador de Tarefas a memória física utilizada estará na coluna “Memory (private) para seu processo específico. No Performance Monitor, o contadores será Memory – Working Set.

Você também poderá acompanhar se há memória disponível no servidor, para identificar se você está com problemas de gerenciamento de memória ou não pelo seu processo, pois a memória disponivel medida é realmente uma memória livre pronta para ser usada por um processo.

O sistema operacional Windows define memória disponível como memória física que não é atribuído a um processo, o kernel, ou drivers de dispositivos.

No Performance Monitor, o contador é Memory – Avalilabe MBytes. Observe que ele informa que o Sistema Operacional possui aproximadamente 14 GB de memória livre.

Esse contador é extremamente importante, pois medindo ele mais o que é usado pelo seu processo, você consegue identificar se há falta de memória no servidor causando lentidão em sua aplicação ou não.

– Contadores dos Processos que Comportam sua Aplicação

Claro que sua aplicação utiliza diversos processos do sistema operacional, e seria complexo medir todos, como por exemplo o famoso SVCHOST do Windows que é praticamente seu CORE. Mas aí que conta a experiência. Resumindo existem processos como:

SPOOLER.EXE: que trata de questões de impressão

W3WP.EXE: que trata de aplicativos Web hospedados no Internet Information Services

Desses processos você poderá usar os contadores Handles (Quantidade de Ponteiros), Memory (Memória Física Utilizada) e Processor (Tempo de Processador)

Scripts e Templates Prontos

Para facilitar, deixo aqui os links para download de uma coleção de scripts Powershell e também de templates para serem usados conforme a necessidade.

– Usando o Template Coletor Servidor – Modelo A

Esse template funciona no Windows 2008, Windows 2012, Windows 7, Windows 8 e Windows 10. Ele possui os contadores de Servidor: Disco, Processador e Memória e de Processo: Handles, Thread, Memória, Disco.

Faça o download aqui!

ou clique diretamente no link: https://gallery.technet.microsoft.com/e-Template-para-uso-no-1218cac8

Abra o Performance Monitor – Data Collector Sets – New – Data Collector Set

Digite o nome do seu Data Collector, em seguida selecione Create from a template.

Escolha o template Coletor Servidor – Modelo A

Clique em Finish. Em seguida clique em Start.

Esse coletor irá funcionar até que se ocupe um espaço de LOG de 600 MB ou se você parar ele antes. e seu diretório padrão será conforme o da imagem.

Você pode alterar as configurações do mesmo nas propriedades, como o diretório, condições de parada, conta que irá executar o coletor (administrador, por exemplo).

Para saber mais, acesse os links abaixo:

O que cada coletor faz

Como ativar via Powershell

Importante: Lembre-se que além dos contadores do Servidor, você deverá também ativar os contadores de processo. No pacote está disponível um Template para o Processo Calculadora do Windows com os principais contadores. Você deverá apenas trocar pelo processo de sua aplicação.

– Analisando os Contadores Coletados

Depois de feito a coleta dos dados do servidor e dos processos que compõem sua aplicação, iremos agora interpretar os dados.

 

Possuimos então os coletores abaixo:

Iremos em Reports – Coletor Servidor

O primeiro contador a ser observado é o Tempo de Processador. No periodo que sua aplicação estava em funcionamento, o porcentagem de ocupação do processador foi em média “average” de 16%, ou seja o processador e seus cores estavam trabalhando tranquilamente, pois foi um valor do conteudo total.

O próximo é a porcentagem de Tempo de Ociosidade do Disco.

Observando, disco ficou na média (average) 99%, ou seja, grande parte ocioso. Se esse numero estivesse abaixo de 20%, seria necessário investigar mais a fundo os processos que estavam causando esse afunilamento no disco e se seria necessário ou ajustar os aplicativos, distribuir cargas ou trocar o disco se sua tecnologia fosse devasada.

Por último, iremos observar a quantidade de Memória Disponível no periodo de execução da aplicação.

Observe que na nossa medição, a média de memória disponivel no servidor é de 15 GB, ou seja, tem memória suficiente no servidor que não foi alocada, mesmo com nossa aplicação em funcionamento.

Conclusão: Na parte de recursos do servidor, não há afunilamento, iremos então observar a parte do processo da aplicação. Caso houvesse algum afunilamento, poderiamos usar outros contadores mais específicos como tempo de escrita em disco, medir cada Core do processador, mas normalmente não é necessário entrar nessa granularidade.

Iremos agora avaliar o processo Calculator como exemplo:

Os coletores são: Handles (Ponteiros), Tempo de Processador, Contador de Thread, Private Bytes (Uso de Memória)

Usando as dicas já citadas acima sobre Handles, Tempo de Processador, Uso de Memória, podemos observar que o processo Calculator está funcionando corretamente, não caracterizando nenhum problema aparente.

Conclusão Final

Sendo assim, chegamos a conclusão de como utilizar tais contadores, pois podemos responder:

– Comportamento do sistema operacional quando sua aplicação está sendo executada;

Na análise acima, percebemos um comportamento adequado a nível de recursos pelo sistema operacional, não havendo consumo excessivo dos mesmos.

– Quais os requisitos ideais de hardware, software e configuração para que sua aplicação funcione corretamente;

No momento da medição, executei diversas operações matemáticas e percebi que o consumo médio de cada item (processador, disco, etc.) foi X. Caso deseje saber o ideal para minha aplicação, simplesmente adiciono os contadores que necessito dentro do Processo, faço as operações de emissão de documentos, gerenciamento, etc. E em seguida tiro a média “Average” necessário e insiro em meu manual.

– Quando há lentidão, se essa lentidão está associada a um afunilamento de recursos e se esse afunilamento de recursos ocorre devido a pouco recurso, uso concorrente de outros aplicativos ou má gestão de recursos de sua própria aplicação.

Não foi identificado nenhum problema de afunilamento.

– Quando ocorre um mal funcionamento de sua aplicação ou servidor, identificar se algum dos recursos estão sobrecarregados ocasionando esse mal funcionamento.

Todos os recursos, Handles, Memória, Processador estavam de acordo.

Espero que esse post ajude e até a próxima!

Fonte: https://qualidadeeti.wordpress.com/2015/11/24/testes-de-softwaremedindo-o-desempenho-de-sua-aplicao/

2 Thoughts on “Testes de Software–Medindo o Desempenho de sua Aplicação

  1. Joel on 25/02/2021 at 12:20 said:

    Não foi encontrado o template XML

Deixe um comentário para Fabrizio Gianfratti Manes Cancelar resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.

Post Navigation