Perca de desempenho com Hibernate?

Hibernate e seja feliz.

Usar hibernate acaba sim sendo bem mais lento que usar JDBC. Se performance é um requisito importante eu usaria iBatis, agora conhecido como myBatis (http://blog.mybatis.org/). Usei há uns 5 anos em um projeto onde o hibernate acabou sendo um gargalo. Não sei como está hoje, mas recomendo dar uma olhada.

+1. Usei em um projeto ano passado onde performance era algo crítico e precisávamos de algumas coisas específicas do banco.
E o projeto é muito bom, vou usar em um que estou começando agora também. No blog da Loyane você encontra bons tutoriais pra começar.

Mas é claro que cada caso é um caso. Você precisa fazer testes e analisar se o hibernate poderá ser um gargalo em seu cenário.

Hibernate é tranquilo. Só tem que procurar usar adequadamente seus recursos. Muita gente usa a forma mais tradicional dele como bala de prata para o sistema inteiro. Então observe alguns pontos, como:

– Criteria aplicando fetch para atender a cada caso de consulta, afim de gerar uma única requisição de SQL. Logicamente todos os relacionamentos deverão estar como lazy.
– Stateless Session
– SQL Nativo (uso bastante em relatórios complexos, onde seria insano usar Criteria ou qualquer tipo de consulta baseado em objetos).

Artigo interessante

javaflex:

Hibernate é tranquilo. Só tem que procurar usar adequadamente seus recursos. Muita gente usa a forma mais tradicional dele como bala de prata para o sistema inteiro. Então observe alguns pontos, como:

– Criteria aplicando fetch para atender a cada caso de consulta, afim de gerar uma única requisição de SQL. Logicamente todos os relacionamentos deverão estar como lazy.
– Stateless Session
– SQL Nativo (uso bastante em relatórios complexos, onde seria insano usar Criteria ou qualquer tipo de consulta baseado em objetos).

Artigo interessante

eu tenho um problema semelhante usando hibernate e jasperreports. Precisei usar o sql nativo porque com datasource de javabeans não tinha condições. dependendo do relatório se você subir tudo aquilo no hibernate vai afogar o sistema nos caches dele.

juliocbq:

javaflex:

Hibernate é tranquilo. Só tem que procurar usar adequadamente seus recursos. Muita gente usa a forma mais tradicional dele como bala de prata para o sistema inteiro. Então observe alguns pontos, como:

– Criteria aplicando fetch para atender a cada caso de consulta, afim de gerar uma única requisição de SQL. Logicamente todos os relacionamentos deverão estar como lazy.
– Stateless Session
– SQL Nativo (uso bastante em relatórios complexos, onde seria insano usar Criteria ou qualquer tipo de consulta baseado em objetos).

Artigo interessante

eu tenho um problema semelhante usando hibernate e jasperreports. Precisei usar o sql nativo porque com datasource de javabeans não tinha condições. dependendo do relatório se você subir tudo aquilo no hibernate vai afogar o sistema nos caches dele.

Se mesmo com todas as boas práticas existentes o Hibernate não lhe atender (o que pode acontecer) vai de myBatis que é sussa.

Além dos citados, deve usar também cache, pool de conexões e etc.

Obrigado pelas opiniões pessoal.
Eu sempre acreditei que Hibernate utilizado com consciência pode ser um grande aliado. Uma pena que nem todos se preocupem com a maneira como o utilizam.
E muito obrigado pela indicação do myBatis, parece ser muito interessante.

Eu vejo que vai mais de quem e como usa o Hibernate do que a ferramenta em si.

Vejo diversas pessoas reclamando da perfomance do Hibernate, mas muitas não sabem desativar o cache, otimizar consultas fazendo com que objetos retornem detached ou até mesmo trazem diversos objetos como Featch.EAGER por pura ignorância. E acaba que a culpa é do Hibernate.

Já li diversos livros falando que a perda de performance é minima, mas ainda assim vale a pena.

Quer uma coisa melhor ainda? Coloque hibernate e faça um teste de carga, detecte onde está o gargalo e coloque ali apenas como JDBC. Desse modo você terá a produtividade do Hibernate e a ‘rapidez’ do JDBC em seu projeto. Uma abordagem híbrida sempre cai bem.

OBS.: meu trabalho é hibernate pra cima e pra baixo e nunca tivemos problemas, e quando apareceu gargalo era problema de desenvolvimento e não do hibernate.

Hebert Coelho:

Eu vejo que vai mais de quem e como usa o Hibernate do que a ferramenta em si.

Vejo diversas pessoas reclamando da perfomance do Hibernate, mas muitas não sabem desativar o cache, otimizar consultas fazendo com que objetos retornem detached ou até mesmo trazem diversos objetos como Featch.EAGER por pura ignorância. E acaba que a culpa é do Hibernate.

Já li diversos livros falando que a perda de performance é minima, mas ainda assim vale a pena.

Quer uma coisa melhor ainda? Coloque hibernate e faça um teste de carga, detecte onde está o gargalo e coloque ali apenas como JDBC. Desse modo você terá a produtividade do Hibernate e a ‘rapidez’ do JDBC em seu projeto. Uma abordagem híbrida sempre cai bem.

OBS.: meu trabalho é hibernate pra cima e pra baixo e nunca tivemos problemas, e quando apareceu gargalo era problema de desenvolvimento e não do hibernate.

A coisa não funciona assim não. O hibernate não atende todas as demandas. Inclusive hoje mesmo estou otimizando um problema desse tipo aqui. Quando o hibernate carrega os objetos e passa pro jasper montar os relatórios ele dá um pico grande de cpu e memória. Eu tenho apenas 1.4 gb para parear centenas de acessos pedindo relatórios. Uma solução de fila é incoerente num sistema que é tido como multitarefas. Então cuidado na hora de generalizar.

Como alguns falaram aqui, é sim possível usar o hibernate de maneira “responsável” e otimizar e muito a sua utilização. A maioria dos problemas de performance com hibernate sem dúvida é falta de conhecimento e “mau uso”.

Entretanto, para casos críticos, simplesmente não acho que compensa o trabalho que normalmente se teria em otimizar o máximo todas as consultas, usar StatelessSession, etc etc etc etc. Ia ser um trabalho muito maior do que simplesmente deixar de usar hibernate e usar outra coisa.

Comentei sobre o myBatis pois já passei por uma experiência parecida e funcionou. Trocamos o código para usar myBatis no lugar de Hibernate. Ainda acho Hibernate uma ferramenta útil para a maioria dos casos, mas o trade-off dele é esse: É prático para programar, mas ao custo de “estimular a baixa performance”.

No mundo ideal você sempre vai ter uma equipe cheia de desenvolvedores ninjas e que sabem tudo de Hibernate, onde seu projeto nunca vai ter esses problemas. Mas o mundo real é um pouco diferente

rodrigo.uchoa:

Como alguns falaram aqui, é sim possível usar o hibernate de maneira “responsável” e otimizar e muito a sua utilização. A maioria dos problemas de performance com hibernate sem dúvida é falta de conhecimento e “mau uso”.

Entretanto, para casos críticos, simplesmente não acho que compensa o trabalho que normalmente se teria em otimizar o máximo todas as consultas, usar StatelessSession, etc etc etc etc. Ia ser um trabalho muito maior do que simplesmente deixar de usar hibernate e usar outra coisa.

Comentei sobre o myBatis pois já passei por uma experiência parecida e funcionou. Trocamos o código para usar myBatis no lugar de Hibernate. Ainda acho Hibernate uma ferramenta útil para a maioria dos casos, mas o trade-off dele é esse: É prático para programar, mas ao custo de “estimular a baixa performance”.

No mundo ideal você sempre vai ter uma equipe cheia de desenvolvedores ninjas e que sabem tudo de Hibernate, onde seu projeto nunca vai ter esses problemas. Mas o mundo real é um pouco diferente

A equipe onde trabalhamos não é formada por juniores. Você está generalizando a máquina em que um programa vai rodar. A do meu problema em questão é uma vm rodando ubuntu server 12.04 e ela possui 1.4gb. Divido memória com o sistema e diversos serviços.

Na sua solução eu deveria aumentar a memória da máquina ou otimizar o software?

Minha solução eu não usei Hibernate. Mas meu caso era muito particular, pois não se tratava só de uso excessivo de memória e também de tempo de resposta em todas as operações de “persistência”. Pelo que entendi do seu problema, uma forma de contornar é usando “stateless session” para “pular o cache”. Em último caso faz SQL na mão. Mas é difícil dar a melhor solução sem conhecer o contexto geral. Estou apenas dando dicas… Ninguém aqui é mágico

juliocbq:

Hebert Coelho:

Eu vejo que vai mais de quem e como usa o Hibernate do que a ferramenta em si.

Vejo diversas pessoas reclamando da perfomance do Hibernate, mas muitas não sabem desativar o cache, otimizar consultas fazendo com que objetos retornem detached ou até mesmo trazem diversos objetos como Featch.EAGER por pura ignorância. E acaba que a culpa é do Hibernate.

Já li diversos livros falando que a perda de performance é minima, mas ainda assim vale a pena.

Quer uma coisa melhor ainda? Coloque hibernate e faça um teste de carga, detecte onde está o gargalo e coloque ali apenas como JDBC. Desse modo você terá a produtividade do Hibernate e a ‘rapidez’ do JDBC em seu projeto. Uma abordagem híbrida sempre cai bem.

OBS.: meu trabalho é hibernate pra cima e pra baixo e nunca tivemos problemas, e quando apareceu gargalo era problema de desenvolvimento e não do hibernate.

A coisa não funciona assim não. O hibernate não atende todas as demandas. Inclusive hoje mesmo estou otimizando um problema desse tipo aqui. Quando o hibernate carrega os objetos e passa pro jasper montar os relatórios ele dá um pico grande de cpu e memória. Eu tenho apenas 1.4 gb para parear centenas de acessos pedindo relatórios. Uma solução de fila é incoerente num sistema que é tido como multitarefas. Então cuidado na hora de generalizar.

Hebert Coelho:

juliocbq:

Hebert Coelho:

Eu vejo que vai mais de quem e como usa o Hibernate do que a ferramenta em si.

Vejo diversas pessoas reclamando da perfomance do Hibernate, mas muitas não sabem desativar o cache, otimizar consultas fazendo com que objetos retornem detached ou até mesmo trazem diversos objetos como Featch.EAGER por pura ignorância. E acaba que a culpa é do Hibernate.

Já li diversos livros falando que a perda de performance é minima, mas ainda assim vale a pena.

Quer uma coisa melhor ainda? Coloque hibernate e faça um teste de carga, detecte onde está o gargalo e coloque ali apenas como JDBC. Desse modo você terá a produtividade do Hibernate e a ‘rapidez’ do JDBC em seu projeto. Uma abordagem híbrida sempre cai bem.

OBS.: meu trabalho é hibernate pra cima e pra baixo e nunca tivemos problemas, e quando apareceu gargalo era problema de desenvolvimento e não do hibernate.

A coisa não funciona assim não. O hibernate não atende todas as demandas. Inclusive hoje mesmo estou otimizando um problema desse tipo aqui. Quando o hibernate carrega os objetos e passa pro jasper montar os relatórios ele dá um pico grande de cpu e memória. Eu tenho apenas 1.4 gb para parear centenas de acessos pedindo relatórios. Uma solução de fila é incoerente num sistema que é tido como multitarefas. Então cuidado na hora de generalizar.

Em nenhum momento eu disse que hibernate á bala de prata esperada a anos. Novamente, vejo muitas pessoas reclamando do hibernate quando a culpa é do desenvolvedor. Mas isso ñ quer dizer que o hibernate é a solução de todos os problemas.

Estranho o juliocbq falar isso ali, sendo que você escreveu que recomenda implementar um híbrido de JDBC e Hibernate. Ele comentou como se você tivesse dito que Hibernate serve pra qualquer caso…

Minha solução eu não usei Hibernate. Mas meu caso era muito particular, pois não se tratava só de uso excessivo de memória e também de tempo de resposta em todas as operações de “persistência”. Pelo que entendi do seu problema, uma forma de contornar é usando “stateless session” para “pular o cache”. Em último caso faz SQL na mão. Mas é difícil dar a melhor solução sem conhecer o contexto geral. Estou apenas dando dicas… Ninguém aqui é mágico :)

A questão não é nem o cache, mas o recurso de cpu e memória que consome naturalmente ao carregar as bibliotecas do jasper. Com pouca memória não há lugar para os dois então a solução nativa é a melhor nesse caso. Aqui a solução também é híbrida. O software todo praticamente usa o hibernate. Só trocamos para o nativo quando o jasper entra em ação(objetos carregados do hibernate para o jasper).

Ruttmann:

Hebert Coelho:

juliocbq:

Hebert Coelho:

Eu vejo que vai mais de quem e como usa o Hibernate do que a ferramenta em si.

Vejo diversas pessoas reclamando da perfomance do Hibernate, mas muitas não sabem desativar o cache, otimizar consultas fazendo com que objetos retornem detached ou até mesmo trazem diversos objetos como Featch.EAGER por pura ignorância. E acaba que a culpa é do Hibernate.

Já li diversos livros falando que a perda de performance é minima, mas ainda assim vale a pena.

Quer uma coisa melhor ainda? Coloque hibernate e faça um teste de carga, detecte onde está o gargalo e coloque ali apenas como JDBC. Desse modo você terá a produtividade do Hibernate e a ‘rapidez’ do JDBC em seu projeto. Uma abordagem híbrida sempre cai bem.

OBS.: meu trabalho é hibernate pra cima e pra baixo e nunca tivemos problemas, e quando apareceu gargalo era problema de desenvolvimento e não do hibernate.

A coisa não funciona assim não. O hibernate não atende todas as demandas. Inclusive hoje mesmo estou otimizando um problema desse tipo aqui. Quando o hibernate carrega os objetos e passa pro jasper montar os relatórios ele dá um pico grande de cpu e memória. Eu tenho apenas 1.4 gb para parear centenas de acessos pedindo relatórios. Uma solução de fila é incoerente num sistema que é tido como multitarefas. Então cuidado na hora de generalizar.

Em nenhum momento eu disse que hibernate á bala de prata esperada a anos. Novamente, vejo muitas pessoas reclamando do hibernate quando a culpa é do desenvolvedor. Mas isso ñ quer dizer que o hibernate é a solução de todos os problemas.

Estranho o juliocbq falar isso ali, sendo que você escreveu que recomenda implementar um híbrido de JDBC e Hibernate. Ele comentou como se você tivesse dito que Hibernate serve pra qualquer caso…

Eu citei isso porque parece que o gargalo sempre é em outro lugar que não seja o hibernate. Eu não estou dizendo para não usar. Eu recomendo até usá-lo nos projetos, mas para soluções mais críticas como essas máquinas virtualizadas da amazon com pouca memória é um caso a se pensar muito.