Café com Tecnologia

Posts Tagged ‘Performance’

Essa semana participei de uma discussão sobre a construção de códigos otimizados.

Qual a melhor forma de se otimizar um código para ganhar desempenho? Escrever o código durante o projeto tentando escrever um código mais eficiente possível ou simplesmente terminar um projeto e depois realizar testes para diagnosticar e otimizar?

Eu diria que a busca por códigos otimizados deve ser constante. Para fazer isso, a melhor maneira é:

• possuir processos de desenvolvimento de software bem definidos. é importante que todos os membros da equipe estejam alinhados com ela.
• possuir profissionais experientes nos projetos. Se seu projeto tiver pessoas menos experiêntes, faça um mentoring sempre que possível. Evolua a equipe, para evoluir o projeto;
• conhecer (as boas e más), praticar e disseminar as boas práticas no desenvolvimento para a equipe;
• utilizar ferramentas que façam auditoria nos códigos.

Já comece qualquer projeto com todos os recursos disponíveis para você construir códigos otimizados.

Hoje existem várias técnicas e ferramentas que podem auxiliá-lo a respeito.

Utilize ferramentas, como Maven, para centralizar suas rotinas para auditoria de código. Exemplos:

• O plugin Checkstyle pode ser usado para você verificar se os códigos estão sendo desenvolvidos seguindo os padrões da SUN. Pode ser customizado para atender seus requisitos.
• O plugin CPD / PMD te apresenta códigos duplicados.
• O plugin FindBugs te apresenta os possíveis bugs em seus códigos.
• Faça testes unitários. Veja alguns recursos que você pode usar: JUnit, DBUnit, JMock2, TestNG, JsUnit, JsMock, ….

Esses plugins podem estar contidos em sua IDE ou executados externamente. Se estiverem na IDE, em tempo de codificação, você poderá ter impactos na performance (tenha um bom PC, ok?).

Há vários outros itens que podem ser usados.

Porém, esse é o cenário perfeito, mas que nem sempre é uma verdade. Muitos projetos são vendidos e gerenciados sem prever os testes. INFELIZMENTE e sem tempo para refactoring.

Em uma recente experiência NADA AGRADÁVEL, solicitaram para que a configuração de timeout do Portal fosse configurado para 12h. O recomendado (InfoCenter, documento de Tunning, Suporte, etc) pela IBM é um timeout de 30 minutos.

Enfim, mesmo avisando as consequências, a configuração foi realizada após o horário comercial, já que necessitaria de um restart no servidor.

No dia seguinte não deu outra: o Portal ficou absurdamente lento e meu servidor passivo foi ativado.

Conclusão: hoje o cliente tem total ciência do problema encontrado e estamos fazendo reduções até chegar a um ponto que atenda aos usuários (que não gostam de fazer autenticação) e que seja suportado pelo Portal.

Recentemente escrevi sobre como fazer uma configuração no JMeter para fazer teste de carga no IBM WebSphere Portal.

Abaixo, vou demonstrar resultados práticos de 2 planos de testes.

Plano de Teste Simples

Neste Plano de Teste foi configurado uma Thread Group com apenas 20 usuários.

Test Plan 01 - Thread Group

Veja o Summary Report deste Plano de Teste.

Summary Report

Plano de Teste mais “puxado”

Os resultados que serão apresentados abaixo são referentes a uma configuração de um Thread Group com 500 usuários e tempo de ZERO segundos, ou seja, simulado 500 requisições simultâneas.

Nessa configuração, o Summary Report apresentou os resultados abaixo.

Summary Report com 500 usuários

Este Plano de Teste executou 90.000 “samples” num tempo de aproximadamente 2 minutos.

Simultaneamente, verifiquei as informações apresentadas pelo “server-status” disponível no servidor IBM HTTP Server.

IBM HTTP Server - Status

É bom SEMPRE fazer um bom teste de carga antes de liberar seu site para produção. Antes, porém, faça as devidas configurações de “tunnig” em seu produto.

Hoje, para que possam ter uma idéia, verifico um máximo de 120 requisições simultâneas, bem menos das 500 configuradas no Plano de Teste.

Esse tipo de teste é uma boa garantia a ser apresentada para seu cliente para configurar os trabalhos realizados pela equipe técnica.