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.
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.
É 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.
É 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[/quote]
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.
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”.
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.
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.
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.
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?
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? [/quote]
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.
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.
Sim, concordo. Talvez eu tenha me expressado mal.
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.
Mas existe alguma ferramenta gratuita que permita identificar hotspots de código?? O Jprofiler está acima das minhas condições e o JMeter só faz teste de carga, pelo que entendi.
É 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[/quote]
Exato. Para isso que existe a opção de definir quem entra no cache.
Application Developer: Monitor, profile, take thread dumps, browse heap dumps (Monitora o que já é falho)
System Administrator: Monitor and control Java applications across the entire network (Verifica o que já é recorrente e constante à error)
Java Application User: Create bug reports containing all the necessary information (Vai me dizer tudo aquilo, que não pensei antes de fazer)
:idea: Pensando nisso, ai Louds lhe sugere um especialista, eu até concordo e conheço um bem caro mesmo mas resolve, porém não posso estimar fatores complicadores real na sua empresa, é uma decisão gerencial.
Mas se fosse optar por um outro lado o que se poderia fazer ?
O Arquiteto não está sabendo especificar o melhor design para uma solução BEA que atenda a plataforma J2EE/JEE, e os desenvolvedores estão implementando código não seguindo esses padrões sem entender melhor esses requisitos, se for buscar instrumentação à entender reflexos por profile esse não projetará no monitor instantaneamente esses aspectos de threads.
