Bom dia galera,
tenho uma aplicação usando JSF,Seam e Hibernate,e algumas requisições estão disparando várias consultas a mais no banco do que o necessário,a ponto de derrubar a aplicação.Qual a ferramenta vcs me indicam pra fazer esse profiling?
Identificar gargalos na aplicação
R
7 Respostas
T
No jdk você tem algumas ferramentas básicas como o jconsole.
Você pode usar com o JMX: http://tomcat.apache.org/tomcat-7.0-doc/monitoring.html, no tomcat, jboss, etc…
No jboss você tem o /jmx-console.
usa o profiler da sua IDE que ja ajuda muito (eu gosto do profiler do netbeans, é simples mas da conta do recado somente pros meus fontes)
ou pode baixar uma ferramenta de profiling e usar como trial somente pra ver seu problema.
Nesse caso você já identificou que o problema é devido a chamadas repetidas ao banco, e não algum consumo misterioso de recursos. Então mais útil que um profiler seria rastrear essas chamadas ao banco.
O que eu sugiro é o bom e velho LOG. Coloque registros de debug em todas essas chamadas, junto com o com o call stack (http://stackoverflow.com/questions/706292/java-determining-current-call-stack-for-diagnostic-purposes) que vai permitir chegar à origem, possivelmente até a camada de apresentação. A partir daí vai ter um pouco mais de informação para saber O QUE exatamente está sendo acionado em duplicidade (por exemplo, a ação no MB foi chamada várias vezes para a requisição? O MB chamou o EJB mais do que deveria? Uma expressão na página está chamando um objeto.getAlgumaCoisa() várias vezes e esse objeto está fazendo consultas? etc…)
R
Bom galera,obrigado pelas respostas.
Pesquisando eu penso que o problema pode ser no DriverManagerDataSource do Spring,que cria as conexões ao invés de reusar.Troquei para o Commons DBCP para ver se resolve.
Referencia:http://mike.hostetlerhome.com/2009/02/20/be-careful-with-drivermanagerdatasource/
Bom galera,obrigado pelas respostas.Pesquisando eu penso que o problema pode ser no DriverManagerDataSource do Spring,que cria as conexões ao invés de reusar.Troquei para o Commons DBCP para ver se resolve.
Referencia:http://mike.hostetlerhome.com/2009/02/20/be-careful-with-drivermanagerdatasource/
Cara se você suspeita que o problemas esteja no seu DataSource e vá troca de datasource da uma olhada no BoneCP bem estável e bem performático
Tem um benchmark -> http://jolbox.com/index.html?page=http://jolbox.com/benchmarks.html
Outra questão eh por que você não deixa seu container gerênciar isso pra você?
As muitas chamadas ao banco, podem ser de atributos da tela que para serem populados vão ao banco consultar, como listas.
Não sei se é isso, pois o jsf chama muitas vezes os métodos get
As muitas chamadas ao banco, podem ser de atributos da tela que para serem populados vão ao banco consultar, como listas.
Não sei se é isso, pois o jsf chama muitas vezes os métodos get
Essa foi uma das minhas suspeitas também.
Por isso dei a sugestão de colocar no log o call stack das chamadas aos métodos que acessam o banco… se for isso então vai dar para rastrear as chamadas até chegar ao “get”.
Isso considerando que o código que acessa o banco é chamado várias vezes. Se esse código é invocado apenas uma vez mas os acessos no banco se multiplicam, aí a coisa ficou feia :shock:
Criado 10 de abril de 2013
Ultima resposta 10 de abr. de 2013
Respostas 7
Participantes 6