Medindo o desempenho de aplicações Web – Parte 3

Nos artigos anteriores (artigo 1 e artigo 2), vimos quais são os tipos de teste de performance que podem ser realizados para garantir o bom desempenho da aplicação, e também como um teste de carga pode nos ajudar a descobrir o quão performática é nossa aplicação.

Nesse artigo veremos o que é, e como pode ser realizado um novo conceito de testes: o PWPO.

De acordo com Steve Souders (um dos gurus na comunidade de desempenho de aplicações web), existem 14 regras mandatórias para garantir uma boa performance em aplicações web. Baseando-se nessa lista, poderíamos adicionar a 15ª regra: a adesão do PWPO.

O PWPO (Proactive Web Performance Optimization) ou em português: Otimização de Performance Proativa, na verdade não se difere muito do famoso teste de regressão desempenho, tendo como a principal diferença, a automação desse tipo de prática, a fim de antecipar o feedback do usuário em relação a performance da aplicação.

De acordo com a Wikipédia o teste de regressão é uma técnica do teste de software que consiste na aplicação de versões mais recente do software, para garantir que não surgiram novos defeitos em componentes já analisados. Se, ao juntar o novo componente ou as suas alterações com os componentes restantes do sistema surgirem novos defeitos em componentes inalterados, então considera-se que o sistema regrediu.

De uma forma geral, a definição é mais simples: Considerando o monitoramento de desempenho dos aplicativos como uma tarefa vigilante e contínua, podemos detectar como as alterações de recursos e correções de bugs, podem afetar o desempenho do aplicativo de forma não intencional.

A abordagem Reativa

Como padrão de mercado, podemos afirmar que a grande maioria das empresas, se preocupam com o desempenho de aplicações de forma reativa, ou seja, o software é desenvolvido com foco na apenas na funcionalidade do sistema:

• Criação do aplicativo;
• Testes funcionais, para assegurar que nada está quebrado;
• Implantação em produção;
• Possíveis usuários furiosos com o desempenho;
• Análise de desempenho em produção e levantando a bandeira vermelha;
• É hora de melhorar o desempenho e corrigir os problemas do sistema;

Em alguns casos, fabricas de software, aplicam as diretivas de performance do google, para indicar a preocupação com o desempenho da aplicação, no entanto, hoje em dia é necessário mais que isso, é necessário se antecipar ao feedback do usuário.

A abordagem Proativa (PWPO)

Adotando o PWPO a performance do sistema deixa de ser um requisito não funcional, passando a fazer parte do processo de desenvolvimento, sendo um fator com poder vetar uma possível promoção da release ao ambiente de produção:

• Criação do aplicativo;

• Testes funcionais, para assegurar que nada está quebrado;

• Analise de desempenho da aplicação;

  • Em caso de falha, a release volta para o desenvolvimento.

• Avaliação e comparação com o ambiente de produção;

  • Caso haja regressão, a release volta para o desenvolvimento.

• Implantação em produção;

• Possíveis usuários satisfeitos com o desempenho;

• Análise de desempenho em produção;

  • Sempre há alguns milissegundos para apertar a fim de melhorar o desempenho.

PWPO é igual a TDD?

Não. Apesar de ambas as práticas visarem priorizar o teste no ciclo de desenvolvimento, a finalidade é diferente. O TDD é uma prática para construir um aplicativo dirigido por testes unitários, enquanto PWPO tem foco em performance da aplicação.

Como adotar uma solução PWPO?

O PWPO parte da premissa que já existe um ambiente de integração contínua consolidado à plataforma de desenvolvimento. Existem diversas ferramentas que compõem um ambiente de IC, olhando para o mercado openSource a referencia para realização de Builds contínuos é o Jenkins.

Eu sempre procuro olhar para três principais pontos na hora de escolher as ferramentas: Integração entre as ferramentas, qualidade dos relatórios e preço.

Nesse caso, o time escolhido foi Jenkins, Maven e JMeter.

Como sabemos, a ferramenta que cria os scripts de testes é o JMeter, no entanto, para automatizar a execução desse script, teremos que integrar o JMeter ao Jenkins, além disso devemos também comparar os resultados de cada release usando o Maven, para integrar as ferramentas utilize plug-ins do Jenkins, Maven e JMeter.

A grande sacada, é que uma vez realizada essa integração, qualquer tipo de testes de feito pelo Jmeter, pode ser automatizado e assim comparando releases do aplicativo em diversos aspectos, um deles pode ser o teste de carga, como visto no artigo anterior.

Jenkins

Jenkins fornece serviços de Integração Contínua (CI), projetado para fazer builds automáticos de um projeto a partir de gatilhos pré-definidos (periódico, a cada push no repositório, ao acessar uma URL, etc).

A ideia é garantir que apenas builds de sucesso possam ser publicados em produção, usando para isso um cartridge Jenkins, disponível na plataforma.

Mais sobre Jenkins aqui

Apache Maven

Apache Maven, ou simplesmente Maven, é uma ferramenta de automação de compilação utilizada primariamente em projetos Java. O projeto Maven é hospedado pela Apache Software Foundation, que fazia parte do antigo Projeto Jakarta.

O Maven utiliza um arquivo XML (POM) para descrever o projeto de software sendo construído, suas dependências sobre módulos e componentes externos, a ordem de compilação, diretórios e plug-ins necessários. Ele vem com objetivos pré-definidos para realizar certas tarefas bem definidas como compilação de código e seu empacotamento.

O Maven baixa bibliotecas Java e seus plug-ins dinamicamente de um ou mais repositórios, como o Maven 2 Central Repository, e armazena-os em uma área de cache local.3 Este cache local de artefatos baixados pode também ser atualizado com artefatos criados por projetos locais. Repositórios públicos podem também ser atualizados.

O Maven é construído utilizando uma arquitetura baseada em plugin, que permite que ele faça uso de qualquer aplicação controlável através da entrada padrão. Teoricamente, isto permitiria qualquer um escrever plugins para fazer interface com ferramentas de construção (compiladores, ferramentas de teste de unidade, etc.) para qualquer outra linguagem. De fato, o suporte e uso para linguagens diferentes de Java tem sido mínimas. Atualmente existe um plugin para o framework .NET e é mantido, e um plugin nativo C/C++ é mantido para o Maven

Mais sobre Maven aqui

Apache Jmeter

Descrição completa do Jmeter nos artigos anteriores (aqui e aqui).

Alguns exemplos de relatórios criados com as técnicas de PWPO usando as ferramentas escolhidas:

Monitoramento de performance:

Alertas de quebra de limite de performance:

Tempo de Resposta X Porcentagem de erros:

Para saber como criar e executar testes de regressão automatizados siga os tutoriais:

How to automate JMeter tests with Maven and Jenkins

Performance Tests with Jmeter, Maven and Hudson

Automating JMeter tests with Maven and Jenkins

Load Testing with JMeter: Part 2 - Headless Testing and Jenkins Integration

Conclusão

O alerta sobre o desempenho da aplicação, não deve ser uma tarefa de seus usuários finais. Sendo proativo com a adoção de testes de regressões de desempenho ao ciclo de desenvolvimento, a função de levantar a bandeira vermelha passa a ser da plataforma de integração contínua, garantindo assim sempre a evolução do desempenho da aplicação.

A adoção da prática PWPO permite a criação de benchmark de desempenho da aplicação, dessa forma, as evoluções de performance tornam-se tangíveis sendo apresentadas em forma de KPI’s para os executivos ou a própria equipe de desenvolvimento.