Como prevenir problemas de performance em sua aplicação

Como prevenir problemas de performance em sua aplicação

Um dos grandes desafios que as empresas de TI enfrentam ao colocar seus sistemas em produção é a impossibilidade de garantir o desempenho e a confiabilidade destas aplicações.

Não raro sites muito visitados não conseguem comportar a quantidade de acessos. Um bom exemplo disto são as falhas que acontecem quando empresas aéreas disponibilizam promoções a partir de um certo horário de um determinado dia. Alguns sistemas têm graves problemas de desempenho em um período específico do dia ou sempre no mesmo dia da semana, o que dificulta bastante o diagnóstico, pois a equipe terá que esperar até o próximo dia para que o erro volte a acontecer.

Em ambiente de desenvolvimento, estes gargalos são dificilmente detectados e na maioria das vezes os responsáveis pelo sistema – já em produção – são chamados com urgência para apagar o incêndio.

No entanto, há uma forma mais satisfatória e mais oportuna para se evitar este tipo de dificuldade: utilizando o Silk Performer da Borland.

O Silk Performer é uma ferramenta robusta e fácil de usar, que permite que você desenhe, construa, execute e avalie testes de carga e performance. Seu principal objetivo é detectar gargalos e falhas na aplicação, apontando as causas destes problemas. Com isto, ele minimiza a probabilidade do sistema não estar de acordo com os requisitos de desempenho.

A criação do teste inicia-se com a utilização do Recorder (imagem 1), que grava todas as ações do usuário e gera um script com base nestas ações. Este, por sua vez, é alterável e bastante fácil de entender, porém não será necessário modificá-lo, pois praticamente todas as tarefas do Silk Performer são executadas por meio dos wizards.

1 - Recorder do Silk Performer

Após a gravação deste script, é possível realizar uma simulação das ações tomadas no passo anterior.

Para tanto, é preciso criar perfis de usuários representativos de seus próprios clientes para esta simulação. Definem-se nestes perfis:

- a velocidade de conexão com a internet;

- o navegador utilizado;

- o tempo médio de resposta do usuário com o sistema;

- usuário e senha, caso esteja conectando em um servidor remoto;

- se imagens serão baixadas do servidor ao acessar o sistema (imagens normalmente são pesadas e sobrecarregam muito a rede);

- outros.

Antes de executar a simulação, é possível também configurar dados dos formulários da sua aplicação. Para cada campo de entrada de dados do seu sistema, podem-se colocar variáveis para que cada vez que a simulação aconteça, uma informação diferente apareça neste campo. Basta cadastrar alguns números, válidos ou não, no Silk Performer para verificar, ao executar o teste, se a validação de um campo (um número de CPF, por exemplo) está correta.

Até o momento, o objetivo principal foi gravar um script abrangente e que atendesse às necessidades para o teste de performance do sistema. O próximo passo é testar este script e analisar os resultados obtidos. Parte das informações colhidas compreende:

- tempo de resposta das transações (mínimo, máximo, médio);

- tempo em que o servidor esteve ocupado (server busy);

- quantidade de dados enviados e recebidos em cada formulário;

- descrição dos erros, caso ocorram;

- outros.

Estes dados são gerados em forma de relatório, mas também podem ser gravados em um repositório.

Se os resultados estiverem em um nível aceitável, basta então aprovar este script e seguir para o teste propriamente dito.

Há, no Silk Performer, seis modelos de teste de carga e performance:

• Queuing

•Cada usuário virtual inicia suas transações após certo tempo de espera na fila.

•Cada usuário executa suas tarefas apenas uma vez.

•O teste termina quando todos os usuários finalizam suas tarefas.

•O teste pode durar mais do que o tempo de simulação especificado em virtude do tempo de espera.

•Steady State

•Cada usuário começa suas transações sem tempo de espera.

•Há sempre o mesmo número de usuários executando.

•Cada usuário executa as tarefas repetidas vezes até que o tempo de simulação termine.

•Increasing

•Cada usuário começa a executar suas tarefas de acordo com um intervalo pré-estabelecido.

•Cada usuário executa as tarefas repetidas vezes até que o tempo de simulação termine.

•Este tipo de teste é importante para detectar em que momento o sistema ‘cai’ ou passa a fornecer tempos de resposta inaceitáveis.

•All Day

•Cada usuário começa e termina o teste de acordo com intervalos pré-estabelecidos.

•Cada usuário executa as tarefas repetidas vezes até que o tempo designado a ele termine.

•A carga é ajustável durante o teste.

•Este tipo de teste é útil para se representar cenários complexos e de longa duração.

•Dynamic

•Cada usuário começa e termina suas tarefas de acordo com as mudanças manuais feitas pelo executor do teste.

•Cada usuário executa as tarefas repetidas vezes até que seja interrompido.

•Um número máximo de usuários é escolhido e, de acordo com este limite, pode-se aumentar e diminuir a quantidade de usuários.

•É preciso parar o teste manualmente.

•Verification

•Um único usuário executa suas tarefas apenas uma vez.

Durante a execução dos testes é possível monitorar alguns dados: utilização de CPU, utilização de memória e a rapidez com a qual o computador se torna disponível para resolver a próxima tarefa. Se algum destes dados exceder um limite tolerável, é necessário desconsiderar as informações deste teste, pois seguramente o mau desempenho da máquina irá interferir nos resultados obtidos.

Concluídos os testes, faz-se a análise dos resultados finais. Informações - tanto do lado do cliente quanto do servidor - são colhidas e indicam onde está o problema. Gráficos são recursos muito interessantes para o exame de dados. Eles são produzidos ‘arrastando e soltando’ as informações do relatório gerado na área de criação do gráfico.

Há alguns exemplos de gráfico que podem fornecer informações esclarecedoras.

2 - Aplicação estável

A imagem 2 mostra uma aplicação estável, cujos indícios são:

- Não há erros. Estes seriam representados por uma linha vermelha (Errors/sec)

- A linha que representa transações/segundo (verde claro) cresce acompanhando a linha dos usuários ativos (linha azul), demonstrando que o servidor está conseguindo suportar as requisições.

- As linhas que representam dados enviados (verde escuro) e dados recebidos (laranja) seguem de acordo com a linha dos usuários ativos (linha azul), indicando que não há problemas na rede.

3 - Aplicação com problemas no servidor

Observa-se, na imagem 3, alguns indicativos de que esta aplicação pode estar com problemas em seu servidor: as linhas que representam transações/segundo (verde claro), dados enviados (verde escuro) e dados recebidos (laranja) começam a decrescer por volta de 20 usuários (note a linha azul, no ponto 20 do eixo y, onde as outras linhas começam a indicar problemas).

4 - Aplicação com problemas na rede

Possíveis problemas na rede são representados na imagem 4, pelos seguintes motivos:

•Erros aparecem por volta de 70 usuários.

•A linha que representa conexões concorrentes (roxa) começa a nivelar, indicando um provável problema de rede.

•A linha que representa dados enviados (verde escuro) e também a linha laranja (dados recebidos) seguem a linha de usuários ativos (azul), demonstrando não haver um problema no servidor.

Silk Performer é a ferramenta da praticidade e da eficiência que, sem exigir nenhum conhecimento de programação, torna possível criar um script de teste e aplicá-lo em um sistema para detectar problemas de servidor ou de rede, mas que pode também levar à conclusão de que sua aplicação está estável e pode entrar em produção sem problemas de performance.