Pessoal, gostaria de saber se há diferença em relação a desempenho quando utilizamos conexão direta com JDBC e Hibernate ?
Seguinte… tenho um list que utilizando conexão direta com JDBC + prepareStatement, a página demora + - 10933 ms para carregar… já utilizando Hibernate (Query Nativa, por necessidade de usar função proprietária do banco Oracle) demora + - 36844 ms.
Sim. Se você fizer tudo direto usando JDBC, sua performance será significativamente maior.
Agora, se você for levar em consideração tempo de desenvolvimento, aí com Hibernate você terá seu projeto pronto anos luz à frente do que apenas com JDBC. [:)]
Você tem de levar em consideração de que, ao utilizar o Hibernate, você não está interagindo “direto” com o banco, mas sim com mais uma camada, que se sobrepõe, por sua vez, acima do JDBC.
Agora, o contrário pode acontecer. Você também pode obter consultas mais rápidas com o Hibernate (em alguns casos), devido às otimizações que ele efetua sobre o SQL que vai gerar.
Mas em uns 70% dos casos, o JDBC é mais rápido, sem dúvidas.
kicolobo, então tenho um problema na minha mão, já que o Gerente e o Cliente não querem saber se usei ou não hibernate… eles querem desempenho no processo !!!
Seria uma boa prática usar hibernate, mas em casos que o desempenho não seja bom, usar o bom e velho conexão direta com JDBC ?? O que isso me implicaria ??
Olha, cada caso é único.
Você pode, se quiser, optar por usar apenas JDBC. Vai ficar realmente muito mais rápido, mas em contra partida, vai te dar mais trabalho pra desenvolver também.
Ou então, pode usar a seguinte alternativa: faça tudo com Hibernate. E em seguida, utilizando um profilador, encontre as consultas mais lentas e, nestes casos, utilize JDBC. Recentemente tive de fazer isto num sistema.
Havia uma consulta que levava 30 segundos para executar usando o Hibernate. Utilizando JDBC, conseguimos reduzir o tempo para algo em torno de 200 ms (!!!). No caso, esta consulta já preencha os beans utilizando o Hibernate (estávamos usando um objeto Criteria). O que fizemos foi apenas reescrever a busca que buscava pelos campos chave dos registros que seriam representados pelas entidades e, um a um, utilizar o próprio Hibernate para preenchê-los. Mantivemos assim neste caso a mesma produtividade que teriamos originalmente com a ferramenta.
Outra opção consiste em otimizar o próprio Hibernate. Você pode fazer isto utilizando por exemplo consultas em lote, desligando ou habilitando o cache secundário (vai depender do caso), dentre diversas outras opções.
(aqui segue um link do próprio Hibernate sobre como usar processamento em lote: http://www.hibernate.org/hib_docs/reference/en/html/batch.html)
Outra opção: utilize lazy loading (sempre lembrando: há casos e casos). Assim você não carrega todas as dependências de suas classes de cara e ganha alguma performance.
Agora, se é uma boa prática ou não, não sei te responder. O resultado final só depende de você.
[quote=marceloplis]kicolobo, então tenho um problema na minha mão, já que o Gerente e o Cliente não querem saber se usei ou não hibernate… eles querem desempenho no processo !!!
Seria uma boa prática usar hibernate, mas em casos que o desempenho não seja bom, usar o bom e velho conexão direta com JDBC ?? O que isso me implicaria ??
Valew.[/quote]
Eu acho que em pontos críticos vale à pena sim, mas somente quando a performance for realmente um fator que está fazendo diferença. Os seus milissegundos não dizem nada se forem números isolados. Você precisa quantificar isso. Quanto de “demora” é aceitável e quanto não é? O usuário final vai perceber esse ganho de performance ao se deixar de usar o Hibernate e partir para JDBC? Porque se o usuário não perceber diferença, você teve um p*** trabalho com JDBC à toa…
[quote=kicolobo]…
Ou então, pode usar a seguinte alternativa: faça tudo com Hibernate. E em seguida, utilizando um profilador, encontre as consultas mais lentas e, nestes casos, utilize JDBC. Recentemente tive de fazer isto num sistema.
…[/quote]
O que acontece (na maioria dos casos) em relação ao hibernate é que as consultas que ele gera nem sempre são otimizadas e o ideal é fazer um trabalho de otimização em cima. Otimizar as sqls que ele gera está um pouco além do trivial e muitas vezes é necessário um conhecimento do funcionamento do banco, para entender onde estão os gargalos, e até contar com a ajuda de um DBA.
Obviamente o hibernate é mais lento que JDBC puro, até porque o hibernate é uma camada a mais que roda em cima de JDBC… mas uma consulta de 200 ms demorar 30 segundos demonstra que há algo de errado… a diferença de performance do hibernate não é tão gritante assim e é passível de configuração, até chegar um nível ideal de performance de funcionamento e de desenvolvimento.
Seguinte: um profilador é um programa que você utiliza para verificar o desempenho do seu sistema. Ele te fornece por exemplo quanto tempo cada função do seu sistema está levando para executar, o que, por sua vez, você pode usar para descobrir os gargalos.
Depois me lembrei de uma outra opção para resolver seu problema. Se você estiver querendo editar registros, utilize stored procedures. O processamento irá todo para o SGBD (que lidará com a stored procedure muito bem) e seu cliente fica livre “na hora”.
Conexão com Remoto_Cliente: Hibernate = 44 seg. JDBC = 2 min.
Agora, o que mais me deixou com os cabelos em pé…
Conexão com Local_Cliente (Instalei a aplicação no servidor do Cliente): Hibernate = 10 min. JDBC = 15 min.
A conexão Local_Cliente deveria ser bem mais rápida, mas foi a mais lenta !!! E pq no banco teste a conexão JDBC foi mais rápida e no Remoto foi a Hibernate ??
Neste caso é normal. O Hibernate pode estar usando um pool de conexões por exemplo, e como consequencia, finalizar o processo de conexão pode ser mais demorado mesmoo.
A string de conexão é a mesma nos dois casos?
Nem sempre a conexão local (e principalmente a execução das suas consultas e procedimentos) é a mais rápida. Você tem de ver que, se estiver executando sua aplicação a partir de uma IDE como Eclipse ou Netbeans (que devoram memória), a performance do sistema acaba caindo mesmo.
Agora, seus dados estão realmente descrepantes. Verifique se a instalação do SGBD está correta, assim como a sua rede. Verifique por exemplo se o seu SGBD possui alguma restrição de recursos para o seu usuário (por exemplo um delay entre conexões para o seu usuario específico (pode acontecer. No MySQL por exemplo, você pode configurar isto)).
Algo que costuma melhorar a performance da conexão com o SGBD costuma ser você referenciar o servidor não pelo seu nome, mas sim pelo seu endereço de IP. Não é uma boa prática (absolutamente), mas costuma melhorar, e tendo em vista que os servidores costumam ter um IP fixo, pode ser que lhe ajude de alguma maneira.
Sim, eu uso a mesma string de conexão, só muda o IP do servidor dependendo qual banco vou logar ou qual servidor vou hospedar a aplicação.
Veja, onde demora 15 min. no cliente que testei… em um outro cliente demorou 1 min. A única diferença é que o cliente que teve uma demoa de 15 min. é que ele tem 300 registros a mais que o que demorou 1min. To achando que o problema está no servidor web.
Será isso mesmo ?? o que posso fazer pra resolver ??
P.S. : 1 Min é um tempo alto pra trazer 750 registros ?? eu acho q sim, e vcs, o q me falam ??