Pular para o conteúdo principal

Monitoramento da performance de um servidor


Olá!

O objetivo desse post é inicar o assunto Teste de Performance no QA House.

O post consiste em uma abordagem prática do monitoramento de recursos de uma máquina (por exemplo Web Server, App Server, DB Server, etc.) Existem ferramentas específicas para fazer tal monitoramento, porém, para aprendizado independente de ferramentas e suas peculiaridades, utilizaremos a ferramenta Perfmon do Windows (no caso o Windows 7).

Utilizando o Perfmon pode-se monitorar recursos da máquina como, por exemplo, memória e processamento.

Supondo que será necessário monitorar um servidor durante uma hora, devido a um teste de carga no mesmo:

Criando um conjunto de coletores de dados

1. Abrir o Perfmon (executar > perfmon.exe);
2. Acessar a pasta "Conjuntos de Coletores de Dados" > "Definido pelo Usuário";
3. Clicar com o botão direito na pasta "Definido pelo usuário" e selecionar Novo > Conjunto de Coletores de Dados;

Criando novo Conjunto de Coletores de Dados


4. Nomear o novo conjunto coletor de "Teste de Performance";
5. Marcar a opção "Criar usando um modelo";
6. Clicar em avançar;
7. Escolher o modelo Básico;
8. Salvar o conjunto coletor de dados.

Verificando e alterando as propriedades do coletor de dados

1. Clicar com o botão direito no novo conjunto coletor de dados (do exemplo: "Teste de Performance");
2. Clicar em Propriedades;
3. Verificar duas abas que merecem destaque: "Agendar" e "Condição de Parada".

Na aba "Agendar", o responsável por monitorar o comportamento do servidor pode agendar os dias em que o servidor será monitorado. Por exemplo: uma aplicação que tem um grande número de acessos no horário do almoço. O responsável pode agendar o monitoramento para todos os dias da semana de 12:00 às 14:00.


Na aba "Condição de Parada", o responsável define a duração de cada monitoramento e os limites de tamanho de arquivo ou por tempo de duração. Isso é muito útil em caso de monitoramentos repentinos e também para a definição do tamanho dos arquivos de log.


Definindo quais dados serão coletados

1. Selecionar o conjunto coletor de dados;
2. Serão exibidos ao lado direito da tela, 3 itens. Clicar duas vezes no item "Contador de Desempenho";
3. Verificar os dados que serão monitorados;
4. Adicionar novos dados:



4.1. Clicar no botão Adicionar;
4.2. Selecionar o item Memória;
4.3. Clicar em Adicionar >>;
4.4. Clicar em OK;
4.5. O novo item a ser monitorado será listado.

O responsável pode também selecionar subitens específicos de cada item.

Iniciando o monitoramento e verificando os dados coletados

1. Após salvar as opções do contador de desempenho, e configurar a condição de parada para duas horas de duração, selecionar o conjunto de coletores de dados ("Teste de Performance" e clicar no ícone da seta verde para a direita (Iniciar conjunto de coletores de dados) no topo da página;
2. Aguardar duas horas e acessar a pasta de logs. A pasta de logs está definida dentro das propriedades do conjunto coletor de dados, na aba pasta;
3. Abrir a pasta de logs;
4. Verificar os arquivos de log:

Na pasta de log, destacam-se os seguintes arquivos:

Performance Counter ou Contador de Desempenho




report.html


A partir daí é só fazer a análise dos resultados (este assunto será abordado em outros posts pois é um assunto bem vasto). O interessante é que podemos extrair gráficos de desempenho bem significantes a partir do Performance Counter e também retirarmos informações resumidas e pontuais do report.

Dúvidas? Críticas? Sugestões?

Comentários

Postagens mais visitadas deste blog

Testes no RUP (Parte 2)

Em muitas organizações, os testes começam muito tarde no processo de desenvolvimento de um software. Muitas vezes, começam tão tarde que o produto é lançado com uma quantidade irrisória de testes executados. Para solucionar esse problema, muitas empresas estão começando a adotar testes como um 'mal necessário'. Como contraste a esse panorama, o RUP modifica a abordagem de testes, distribuindo a mesma no decorrer do ciclo de desenvolvimento do software, agregando valor ao invés de arcar com custos excessivos decorrentes da ausência de testes. No post anterior , justificamos a pergunta 'por que testar cedo e com frequência?' com o gráfico de custos. A seguir vocês podem ver um gráfico similar, retirado do site da IBM (detentora da metodologia RUP): Muitas pessoas ainda veem a disciplina de Testes como algo secundário, por que isso acontece? Talvez porque não esteja diretamente ligado ao desenvolvimento do software e por isso é muitas vezes deixado para o final, depois do

O + do FURPS+

Segue a continuação do assunto FURPS: Posteriormente à definição do modelo FURPS, notou-se a necessidade da inclusão de mais atributos para encorpar e aumentar a cobertura do modelo. A partir dessa extensão, o acrônimo passou a ser mais comumente chamado de FURPS+ . Quais são os atributos do “+”? O + do FURPS refere-se a especificação de restrições que definirão determinados limites que deverão ser atendidos quando construímos um sistema. O + é composto dos seguintes requisitos não-funcionais: Design constraints – restrições de design: design nesse caso refere-se ao projeto, diretrizes e não a layout. A definição da utilização um banco de dados relacional no projeto é uma restrição de design, por exemplo. Implementation constraints – restrições de implementação: relacionado a limites impostos a código e construções. Como exemplo podemos citar a linguagem de programação que será utilizada para a codificação de um sistema. Interface constraints – restrições de interface: diretamente l

FURPS

Olá! Nesse post, pretendo falar um pouco sobre o modelo FURPS para ilustrar atributos que estão envolvidos em Qualidade de Software : Vamos começar pela sigla FURPS: o que significa cada uma dessas letras? Do F temos Functionality, traduzimos como Funcionalidade: Representa basicamente os requisitos funcionais do sistema. Do U temos Usability, traduzimos como Usabilidade: Representa basicamente a interface sistema-usuário. Do R temos Reliability, traduzimos como Confiabilidade: Representa basicamente a eficiência e o índice de falhas do sistema. Do P temos Performance, traduzimos como Desempenho: Representa basicamente tempos de resposta e capacidade de processamento do sistema. Do S temos Supportability, traduzimos como Suportabilidade: Representa basicamente esforços necessários para manutenção e configuração do sistema. As definições acima representam o básico de cada uma das letras que compõem a sigla FURPS. A seguir entraremos em detalhes sobre cada uma das categorias, não ante