Performance de uma aplicação

Dificilmente esse tipo de respostas voce nao vai conseguir em um forum, e sim com uma consultoria de alguem especializado em performace.

mesmo assim fica algumas dicas

O System.gc nao deve ser usado explicitamente.
O uso da classe nao afeta. muitas instâncias dela sim

Uma vez eu fui em uma empresa de Cartoes pra ver um problema de performance em um ambiente maluco, 60% era problema em codigo, 40% de ambiente e configuracao de JVM.

Se o código está usando System.gc explicitamente, é porque alguém teve algum problema (conexões que foram deixadas abertas e estouraram o pool de conexões, por exemplo, ou arquivos que foram esquecidos abertos) e deixou essa bomba no código.
Código escrito corretamente não precisa chamar explicitamente System.gc.

Uma dica:

Use um profiler. Ele analisará a execução de seu programa e te dirá exatamente onde estão os problemas de performance.

O eclipse possui um profiler, o Netbeans possue um profiler.
No caso de você não usar nenhum desses dois, tem alguns gratuitos como o Extensible Java Profiler:
http://ejp.sourceforge.net/

Nunca abra mão de um código claro por um menos claro e mais rápido, a menos que esse seja um ponto onde a performance é crítica e só um profiler pode te mostrar esses pontos.

Procure aplicar padroes de projeto, e revise suas consultas ao banco de dados.

Vocês precisam fazer profiling e testes de performance. Fizeram isso? Qual foi a metodologia utilizada? Ou sairam simplesmente “otimizando” o que pareceria precisar de atenção?

Uma pessoa pegou a aplicação para ser otimizada e foi olhando o que precisava ser melhorada. Não houve nada de profiling. E esta aplicação que deveria ser mais rápida, ficou mais lenta, praticamente inviável. Chega em alguns momentos que fica muito lento, impossível.

Estou tentando baixar e usar esse profile do eclipse que um colega disse aí acima, mas ainda não consegui. Na verdade não sei como usar ainda.

Viviane

O que poderia ser problemas na JVM? E como poderia resolver?

Estou tendo um problema muito parecido ao descrito neste tópico, porém tudo que poderia ser feito no código já foi feito.

O que poderia ser alterado nas configurações da JVM, já que citaram anteriormente um exemplo onde isto significou até 40% dos problemas de performance?

Att,

Sokoban

Se a “otimização” não funcionou, eu recomendo que vocês desfaçam todo e qualquer código que tenha ficado menos claro por causa dela. Se não otimiza, não tem porque ficar feio.

Não tem muito segredo para usar o EJP. Basicamente, é só seguir o que está no manual. Não sei se você achou, mas o manual dele é esse aqui.

Instalar o profiler do eclipse é muito fácil.
Entre em help, software updates, find and install
Clique em search for new features to install
Selecione a opção Callisto Discovery Site e clique em finish
Escolha um dos mirros do callisto
Na próxima tela, abra a pasta do Callisto Discovery Site. Abra também a pasta Testing and Performance e selecione os profilers adequados pro seu tipo de aplicação (deve ser o Profiling for web applications).
Para garantir, clique em Select Required. Isso também selecionará os plugins que o profiler depende.

Prossiga a instalação aceitando contrato, etc…

Depois que for instalado, além da opção run as… deve aparecer a opção profile as…

Quanto à configurações da JVM… geralmente o problema não é esse. Vale a pena executar o profiler algumas vezes antes de desconfiar disso… Além do mais, otimizações na VM dificilmente são multi-plataforma.

Dicas de tunning podem ser encontradas no site:
http://www.javaperformancetuning.com/tips/index.shtml

Muito obrigado vini!

E quanto aos compiladores JIT e GCJ? Posso utiliza-los em minha aplicação J2EE (rodando no tomcat)? (desculpem insistir um pouco nisto)

Tenho lido à respeito em alguns lugares, e dizem aumentar a perfomance em troca apenas (basicamente) de portabilidade.

Alguem já utilizou algum deles na prática? Obteve resultados satisfatórios? Conseguiram perceber alguma diferença significativa?

Se puderem me dizem algo a respeito, ficarei muito grato!

Normalmente os principais motivos para performance estão nas operações que lidam com BD ou que lidam com a rede. Ao fazer o profiling dê uma atenção especial nestes pontos. Já adianto que dificilmente ficar chamando System.gc() vai adiantar…

Na revista MundoJava numero 17 eu escrevi um artigo sobre a otimização de performance para aplicações distribuídas (neste caso focando o fator “rede”). Talvez ajude em alguma coisa:

http://www.mundojava.com.br/NovoSite/17destaque.shtml

Sokoban:

Muito obrigado vini!

E quanto aos compiladores JIT e GCJ? Posso utiliza-los em minha aplicação J2EE (rodando no tomcat)? (desculpem insistir um pouco nisto)

O JIT já é usado por default.
Na prática não faz muita diferença pôr o switch “-server” ou “-client” se sua aplicação tem problemas.
Não aconselho o uso do GCJ para resolver problemas de desempenho - provavelmente seu problema não se resolverá só precompilando os programas.

Coisas que ajudam se você não pode mexer na aplicação:

• Memória, memória e mais memória
• Um disco rápido também ajuda
• Ver se você pode deixar o banco de dados em uma outra máquina, mas ligado por uma interface de rede mais rápida (gigabit, por exemplo).

Hmmm, ok vcs me conveceram a não me enveredar nesta área! Reparando bem nas datas, a maioria dos artigos que falam das “mil maravilhas” do JIT, são de 1997/1998, por aí…
Com certeza hoje em dia a JVM já sabe quando compilar ou não o código em linguagem nativa…

Coisas que ajudam se você não pode mexer na aplicação:

• Memória, memória e mais memória

• Um disco rápido também ajuda

• Ver se você pode deixar o banco de dados em uma outra máquina, mas ligado por uma interface de rede mais rápida (gigabit, por exemplo).

Obrigado pelas sugestões, mas receio não ter como ir para este lado, principalmente por limitações de verba, etc…

Voltando na parte de código e estrutura da aplicação, [color=red] poderia o OJB ter algum tipo de incompatibilidade com o pool do tomcat[/color]?
Assim como a viviane, estou utilizando o pool do tomcat através da configuração do arquivo de contexto.
Após implantar o pool de conexões no tomcat, percebi que trechos de código que usavam OJB estavam muito lentos. Já tentei várias configurações diferentes do pool, e realmente está muito Além disso, certos parametros do pool não funcionam! (Ex.: InitialSize)
Substituindo-os por conexao via JDBC, melhora na perfomance foi notável!
No entanto a aplicação foi totalmente estruturada utilizando-se o OJB.:roll:

Qualquer ajuda será muito bem vinda.

Ps.: Viviane, você teve algum problema utilizando o pool do tomcat?

É, tá difícil aqui. Não conseguimos descobrir o porquê da queda de performance.
Vou dar mais algumas informações a respeito, talvez alguém possa me ajudar.
A aplicação anteriormente rodava no Tomcat 4.1 e aproveitamos para atualizar para o Tomcat 5.5. Usamos também o OJB, não sei se alguém conhece, mas nada mais é que uma framework O/R, tipo o hibernate.

Ao fazer alguns teste de stress, percebemos que a aplicação está agarrando em pontos onde a consulta ao banco deveria ser rápida, por exemplo, busca de um registro pela chave primária numa tabela de apenas 400 registros.
Uma desconfiança seria uma incompatibilidade do OJB com o Tomcat 5.5, mas não encontramos nada a respeito. Poucas pessoas conhecem o OJB então por isso temos problemas com suporte.

Se alguém puder me ajudar…

Obrigada,

é, parece que temos dois problemas muito parecidos então…
esse OJB só ta trazendo dor de cabeça.

será que alguem aí tem alguma informação?

já pesquisei, mas não encontro nada falando sobre isso diretamente…