Performace em Portais Corporativos

Pessoal,

Estou trabalhando num portal que apresenta serios problemas de performance, não aguentando nem 500 usuários em uma arquitetura que, segundo o fabricante, suporta mais de 5000. Ja analisamos o código e fizemos algumas alterações mas gostaria de saber de vocês algumas dicas ou sites que possam ajudar nesse trabalho.

Estamos trabalhando com BEA Portal 10MP1, JSF-RI 1.2 e Hibernate 3. Ainda não habilitamos o cache level 2 do Hibernate e o JSF está persistindo os objetos no cliente ao invés do servidor.

Obrigado!!

Meu caro, existem diversos fatores que podem comprometer a performance da sua aplicação. Produtos de caixinha para grande volume de acesso simultâneo geralmente são complicados de ajustar.
Eu não conheço esse produto da Bea. Nunca usei. Com as informações que você passou, a única coisa que posso te dizer é pra você com urgência habilitar o second-level cache do Hibernate.

[]s

Emerson Macedo wrote:Com as informações que você passou, a única coisa que posso te dizer é pra você com urgência habilitar o second-level cache do Hibernate.

É comum utilizar bases de dados compartilhadas com outras aplicações quando construímos portais. Não sei se é o caso, mas creio que isto deve ser observado antes de definir este nível de cache.

[]s

Entusiasta Java Membro desde: 07/07/2007 15:26:14 Mensagens: 15 Offline

Use uma ferramenta de profiler antes de qualquer manutenção! Gosto do JProfiler.

Laércio Queiroz wrote:

Emerson Macedo wrote:Com as informações que você passou, a única coisa que posso te dizer é pra você com urgência habilitar o second-level cache do Hibernate.

É comum utilizar bases de dados compartilhadas com outras aplicações quando construímos portais. Não sei se é o caso, mas creio que isto deve ser observado antes de definir este nível de cache.

[]s

O portal realmente compartilha a base de dados com o publicador de conteudo, que é uma aplicação a parte. Pensei em habilitar o cache somente para consultas recorrentes que dão bastante trabalho a aplicação. E como o estresse ocorre na maior parte com muitos usuários, colocar o tempo de cache o suficiente para a sessao dos usuários expirar.

almeidar wrote:Use uma ferramenta de profiler antes de qualquer manutenção! Gosto do JProfiler.

Ja usamos o JProfiler aqui... Identificamos uma quantidade absurda de Strings sendo criadas mas nao conseguiamos rastrear o motivo delas surgirem. Depois de um codereview na aplicação, identificamos que todos os logs e as queries da aplicação eram montados usando concatenação de string. Substituimos alguns codigos por StringBuffer e suprimimos os logs quando nao estao sendo usados.

Jah conseguimos diminuir o tempo de acesso ao site pela metade soh com essa alteração... E a memória, a principio, não está mais "topando".

This message was edited 1 time. Last update was at 23/07/2008 12:28:24

Qual é a versão do Java que você está trabalhando?

O StringBuilder é mais performático que o StringBuffer por não ser sincronizado. A não ser que você esteja trabalhando multi-thread aí sim é melhor deixar sincrozinado.

Porém quando você faz concatenação de string, o compilador do java transforma isso em StringBuilder no bytecode, portanto o ganho que você teve deve ter sido por causa do log e não por causa do StringBuffer.

Estamos usando o java 5 aqui...

Quanto ao log o que fizemos foi, antes de cada debug ou trace, colocar um if para ver se aquele nivel estava habilitado. Assim ele nem sequer gerava as strings para fazer a concatenação.

Chame um profissional em performance pois ao que tudo indica vocês estão boiando completamente sobre qual é o problema.

Problemas de performance se resolvem de maneira científica investigando primeiro os hotspots, não otimizando no aleatório.

nicholas.bittencourt wrote:[...]segundo o fabricante, suporta mais de 5000. [...]
BEA Portal

O fabricante mentiu.

Mas, de qualquer forma, faça o que o louds disse.

Eu tambem nao acredito muito nessa realidade deles. Até porque cada sessao do usuário só poderia ter uns 2K se for esse caso, e com JSF e tudo mais acho que fica um pouco complicado.

De qualquer forma a aplicação já está bem melhor, com o tempo caindo para 1/5 do inicial, depois da implementação de algumas das dicas mostradas aqui e outras melhorias que fizemos. Realmente programar as 3 da manha afeta a qualidade do codigo...

Como o loud sugeriu, vamos encaminhar agora a um especialista para que faça um code review mais detalhado e aponte as falhas da aplicação. Acho que com isso teremos um ganho bem maior.

Obrigado a todos pelas dicas!

Entusiasta Java Membro desde: 07/07/2007 15:26:14 Mensagens: 15 Offline

Problemas de performance se resolvem de maneira científica investigando primeiro os hotspots, não otimizando no aleatório.

Ok louds, porém um trecho de código que está sendo muito executado pode ser elegido pela VM para ter um hotspot, porém não necessáriamente esse trecho pode ter problema de perfomance, concorda? Por exemplo um comando 'for' pode ser executado muitas vezes e ser performado pelo JIT, porém o gargalo pode estar no banco de dados. Não seria mais interessante focar em tempo de processamento (CPU ) a partir da ferramenta de profiler?

almeidar wrote:

Problemas de performance se resolvem de maneira científica investigando primeiro os hotspots, não otimizando no aleatório.

Ok louds, porém um trecho de código que está sendo muito executado pode ser elegido pela VM para ter um hotspot, porém não necessáriamente esse trecho pode ter problema de perfomance, concorda? Por exemplo um comando 'for' pode ser executado muitas vezes e ser performado pelo JIT, porém o gargalo pode estar no banco de dados. Não seria mais interessante focar em tempo de processamento (CPU ) a partir da ferramenta de profiler?

Oque foi que eu escrevi? Hotspots são os pontos da aplicação responsáveis pela maior fatia de um recurso, Seja ele CPU, memória, tempo de resposta, ou qualquer que seja o problema. Um profiler não é a única ferramenta a ser utilizada, principalmente em aplicações n-tier.

Fora isso, não faz sentido falar "ser performado pelo JIT", isso é irrelevante quando se está estudando a performance de uma aplicação uma vez que todos pontos de interesse necessariamente já terão sido compilados para código nativo.

Aleḿ do que, é quase inútil otimizar código que é responsável por quase nada do tempo total de execução, é feito lustrar o interior o cano de escapamento de um carro - ninguém vai notar.

Entusiasta Java Membro desde: 07/07/2007 15:26:14 Mensagens: 15 Offline

Oque foi que eu escrevi? Hotspots são os pontos da aplicação responsáveis pela maior fatia de um recurso, Seja ele CPU, memória, tempo de resposta, ou qualquer que seja o problema.

Certo louds, mas se o gargalo da app for BD?

Um profiler não é a única ferramenta a ser utilizada, principalmente em aplicações n-tier.

Gostaria de saber quais outras ferramentas podemos usar em aplicações n-tier, além do profiler.

O JMeter é interessante, porém primeiro devo resolver a performance e depois fazer teste de carga.

Fora isso, não faz sentido falar "ser performado pelo JIT", isso é irrelevante quando se está estudando a performance de uma aplicação uma vez que todos pontos de interesse necessariamente já terão sido compilados para código nativo.

Sim, concordo. Talvez eu tenha me expressado mal.

Aleḿ do que, é quase inútil otimizar código que é responsável por quase nada do tempo total de execução, é feito lustrar o interior o cano de escapamento de um carro - ninguém vai notar.

Exato! Devemos fazer o design da aplicação bem simples, sem fazer otimizações prematuras. Somente se houver a necessidade aí sim fazer otimizações utilizando as ferarmentas necessárias.

Para quem se interessar:

http://martinfowler.com/ieeeSoftware/yetOptimization.pdf

http://www.akitaonrails.com/2008/7/21/tradu-o-regras-de-otimiza-o

Entusiasta Java Membro desde: 07/07/2007 15:26:14 Mensagens: 15 Offline

Gosto bastante desse assunto e discussões como essas são muito importantes!

Escrevi algo relacionado à performance no post:

http://manifestonaweb.wordpress.com/2008/06/18/escalabilidade-performance/

Notícias, artigos e o maior fórum brasileiro sobre Java