Esse artigo faz parte da revista Java Magazine edição 64. Clique aqui para ler todos os artigos desta edição

white; COLOR: red; FONT-FAMILY: Verdana; moz-background-clip: -moz-initial; moz-background-origin: -moz-initial; moz-background-inline-policy: -moz-initial">

nte o desenvolvimento para detectar e eliminar limitações de escalabilidade, e na fase de homologação e produção, para dimensionar a plataforma de execução do sistema.

 

Otimizando em Java:

O plugin do JMeter é mais um item na extensa lista de ferramentas de análise de desempenho Java da Sun... quase todas relacionadas ao NetBeans. Vejamos:

·       NetBeans Profiler, uma das melhores ferramentas da categoria;

·       VisualVM e VisualGC, recém integrados ao Java SE 6 Update 10 (ver “A memória do Java”, Edição 60) – baseados no NetBeans Profiler;

·       JMeter Kit, o plugin para JMeter discutido neste artigo;

·       Suporte a profiling de aplicações Java ME no novo Java ME SDK 3.0 – também baseado no NetBeans Profiler;

·       Sem falar na excepcional ferramenta DTrace do Solaris 10 – que sendo open source, já foi portada para o MacOSX, e está sendo portada para BSD e QNX. (O Windows infelizmente é fora de questão, pois o DTrace exige forte integração com o kernel, algo que só a Microsoft poderia fazer). O Java SE 6 inclui probes para o DTrace.

 

Em artigos desta coluna, já exploramos diversas vezes o tópico do “desempenho”, mas quase sempre focando na velocidade de execução. Há outras dimensões de desempenho, sendo que em aplicações servidoras, é particularmente importante a escalabilidade: a capacidade de um sistema de atender a um volume de trabalho cada vez maior. Por “volume de trabalho” podemos ter um número maior de requisições, transações ou outras operações no mesmo espaço de tempo. Fica subentendido que para realizar mais trabalho pode ser necessário adicionar mais hardware, porém numa proporção semelhante. Por exemplo, se uma aplicação web atende a 100 requisições por segundo com 40% de uma CPU de 1 GHz, um tráfego de 200 requisições por segundo exigiria 80%. Ou então, migrando para outro servidor com o dobro da capacidade de CPU, as mesmas 200 transações por segundo voltariam a exigir 40% da capacidade. E assim por diante. Neste cenário, dizemos que o sistema escala de forma linear: podemos derivar uma equação simples, como “1 transação = 1 GHz * 40% / 100 = 4 MHz”, e usar esta regra para fazer o dimensionamento: prever a capacidade de hardware necessária para atender a qualquer previsão de carga.

Atualmente, ferramentas de profiling, como o NetBeans Profiler ou o Eclipse TPTP, são comuns e bem conhecidas, facilitando a análise do desempenho das aplicações. Mas estas ferramentas são focadas nos aspectos de velocidade (profiling de CPU), uso de memória (profiling do heap) e concorrência (profiling de threads e monitores). Não possuem recursos específicos para avaliar a escalabilidade da aplicação. Para isto, precisamos de novas ferramentas.

O Apache JMeter

Uma excelente opção para isto é o JMeter, da Fundação Apache. Já publicamos um artigo sobre o JMeter, mas foi há cinco anos (Edição 11) e muita coisa mudou. Uma é o próprio JMeter, muito mais completo. Outra é o surgimento de suporte integrado de IDE, especificamente no NetBeans. O NetBeans já é notabilizado pelo seu excelente Profiler, e o acréscimo do plug-in para JMeter habilita a integração entre todas essas ferramentas – o IDE Java básico, o profiler e o JMeter – facilitando todo o fluxo de trabalho.

Uma ferramenta de teste de carga, como o JMeter, de fato se presta a uma variedade de cenários interessantes:

·       Profiling “de baixa granularidade”: por exemplo, numa aplicação complexa que serve centenas de páginas ou transações distintas, identificar quais delas estão consumindo mais recursos.

·       Análise e escalabilidade: verificar quão bem sua aplicação sustenta o desempenho, à medida que a carga de trabalho ou a capacidade do hardware são modificadas.

·       Diagnóstico de problemas complexos de desempenho: resolver bugs de desempenho que são difíceis de reproduzir e não ocorrem em testes unitários e funcionais. Por exemplo, a aplicação sofre uma queda brusca de desempenho somente quando uma combinação específica de transações executam simultaneamente, devido a uma má estratégia de locking. ...

Quer ler esse conteúdo completo? Tenha acesso completo