Jdbc ou hibernate lento em conexões em rede

q estranho…

as sessões com a base são fechadas após as operações???Pois estas sessões são pesadíssimas…

Sim, todas são fechadas com:

((Session) sessao.get()).close();

O estranho é que localhost não ocorre isto.
Mas pela rede ocorre.

Agora pode ser duas causas, postgresql 8.3 responde lento a requisições de rede. Ou o jdbc é muito lento em consultas pela rede.

olha, no meu trampo temos a base no servidor e a aplicação rodamos local, o banco é SqlServer 2008…

roda tudo fmz…

agora, no seu lugar eu tentaria acessar um banco diferente, pra testar…não conheçu nada de potsgree, então não posso opinar sobre ele…persistindo o problema com outro banco, o problema esta em sua aplicação

Ola turma.

Vasculhando o log do postgresql, não encontrei nenhuma normalidade, tempo de pesquisa normal, tudo normal.
Então resolvi migrar a base de dados para o mysql, para verificar se ocorreria o mesmo.
Com o mysql o sistema comportou na mesma velocidade que o localhost, bem ao contrário do postgresql.

Então creio que não possa ser um problema do hibernate e sim do jdbc fornecido pelo post ou o próprio postgresql.

Checando o log de rede novamente, como mysql o trafego nas mesmas consultas não chegou a utiliza 5% da rede em menos de 1 segundo, em compensação o jdbc e postgresql utilizou 85% da rede por 5 segundos.

Muito estranho.

Abraços.

At.

Leandro Müller

Baixando a ultima versão do jdbc:
postgresql-8.4-701.jdbc4
Com jdk 1.6

Fiz os testes comparando mysql 5.1 e postgresql 8.3
O gráfico do teste HTTP://www.muriki.com.br/arquivos/grafico_jdbc.png

Fazendo os testes com consultas simples pelo pgadm o tempo de resposta é ótimo, e uma outra observação é que essas consultas não trazem mais de 20 registros cada uma, pois todas são limitadas no consulta setMaxResults(20);

O postgresql pode enviar os dados pela rede em outros formatos mais pesados, bits com compressão, coisas do tipo?

Abraços Turma.

At.

Leandro Müller

pow que informacoes legais, eu nunca usei o postgresql, mas pelo que li tudo inidica que eh o problema do banco mesmo. Eu uso o mysql aqui e realmente nos ultimos tempos so tenho a elogiar o banco cada dia está melhor e o desempenho tb. Uso tb o DB2 Express C da IBM, quando é algo que o mysql nao atende devido as limitacoes.

Eu sempre utilizei o postgresql e em rede e nunca tive esses tipos de problemas, até com uma coluna com 1000 registros ele trazia tranquilamente! Acho que pode ser algum problema de configuração em sua maquina ou na maquina onde esta o postgresql!

bom… conheço o Postgres e o MySQL e sei que o mySQL tem a opção de não se trabalhar com integridade referencial (que é o MyIsam).

Muitas vezes, se vc está com o banco lento pode ser problemas com os relacionamentos das tabelas. Muitas vezes pode ser necessário excluir algum relacionamento e tratar a integridade na linguagem de programação para melhorar a performance.

Trabalho bem com o Postgres e com o MySQL e digo que os dois são excelentes bancos e são muito rápidos.

Até mais

Resolvido.

Lendo e relendo resolvi testar a propriedade hibernate.max_fetch_depth conforme especificação do hibernate, parece loucura, mas o problema do trafego foi resolvido.

Vejam no grafico o teste:

http://www.muriki.com.br/arquivos/grafico_jdbc2.png

Reparem que não passou dos 5% de uso da rede, já sem a configuração chega a 70%.

Nem preciso falar da velocidade do localhost, melhorou 40% do desempenho.

Abraços.

mas aonde estava exatamente o problema,na config do hibernate?

Esta era umas das dúvidas, mas pelos testes tudo apresentava que estava no hibernate ou jdbc.
Colocando a propriedade hibernate.max_fetch_depth resolveu o problema.
Então no caso seria uma configuração do hibernate como solução deste problema.

Para aqueles que utilizam hibernate + postgresql peço que façam um teste setando hibernate.max_fetch_depth =0, e vejam se notam diferença.

No meu caso resolveu o problema de trafego rede com o hibernate e melhorou o desempenho no localhost.

Abraços.

Hibernate Documentation:

hibernate.max_fetch_depth: Sets a maximum “depth” for the outer join fetch tree for single-ended associations (one-to-one, many-to-one). A 0 disables default outer join fetching.
e.g. recommended values between 0 and 3

Ou seja, esse problema deveria acontecer em qualquer banco, ele estando em qualquer nó da rede(localhost ou qualquer outro)
Quando vc colocou ele como 0 você não resolveu o problema em si, só amenizou ele.

pode parecer uma pergunta meio idiota mais por via das duvidas… é só isso que está lento via rede ou qualquer coisa está? tipo em testes como copiar arquivo de uma maquina na outra, ou em pings básicos mesmo… em redes locais o tempo de um ping da vida tem que ser 1ms…

edit… dexa pra la…só tinha lido o promeiro post