Servidor para Rodar ERP

é talvez mudar de servidor e utilizar um tomcat dedicado… acredito que deva resolver

Temos toda aquela situação, onde nos foruns na web dizem que tomcat é para aplicações menores, e que para coisas mais pesadas recomenda-se outros servidores de aplicação…

Apartir disso surge a preocupação…heheh…

tente cluster com load banlance

replicação degrada a peformance do banco, não tem jeito. principalmente se o link entre as instancias for ruim. opte pelo tipo assyncrono, caso vc não tenha necessidade de ter o dado replicado no exato momento.

Acho q essa solução proposta pelo Ricardo seria a melhor opção, alem é claro de tirar o banco de dados da mesma maquina.
Acho que não valeria a pena mudar do tomcat para um outro servidor como o Jboss por exemplo, uma vez que voce não utilizara nenhum outro recurso do container.

A dica do cluster é muito boa, mas antes tenta simplesmente colocar o tomcat em um servidor próprio, com bom hardware. O postgresql adora um acesso a disco e isso pode complicar as respostas do tomcat.

Também seria interessante você colocar um nginx/lighttpd/apache na frente do tomcat (proxy) servindo conteúdo estático (css, javascript, algum html, entre outros) e repassando para o web container somente o que realmente interessa.

E por último, não considere apenas o tamanho de sua aplicação. Leve em consideração quantidade de acessos simultâneos, queries no banco de dados (grande parte do gargalo de aplicações)…

Interessante as sugestões do Ricardo e do “khaoz”, de qualquer forma vou ter que fazer uma mudança, principalmente nos servidores, por que alem de todas as informações que mensionei no post, ainda rodamos um PDV Desktop com 12 Caixas neste mesmo banco PostgreSQL.

Quase toda semana temos problemas de lentindão no Tomcat em consequencia de Selects presos no banco, tentei em ultimo caso usar o statementtimeout( com 10 minutos ) do postgres para nao deixar travar tudo mais fui barrado, temos processos de importação de financeiro e PDV do sistema( DataFlex ) antigo de outras filiais que levam 3 horas.

Este é um estudo que estamos( eu e o Adminstrador de Redes/Linux ) fazendo, para tentar evitar o pior,…sugestões são sempre bem vindas…obrigado.

joao.junior:

Quase toda semana temos problemas de lentindão no Tomcat em consequencia de Selects presos no banco …

Esse é o ponto. Da pra ver que o tomcat pode não ser o principal problema e mover ele para um novo servidor, apesar de te trazer benefícios visíveis, provavelmente não vai resolver a situação completamente. Seria interessante ver com algum DBA o que pode ser melhorado nessa questão. No postgresql.org.br tem um boa referência sobre alguns ajustes tanto no postgresql quanto em hardware que você pode fazer, além é claro de analisar como as consultas estão sendo feitas.