Soh um comentário, as vezes, idependente do servidor, o problema pode estar nas suas consultas, uma tabela com 1 milhão de registros, se vc não fizer consultas utilizando algum indice ou se sempre fizer uma consulta na tabela inteira, não vai haver banco ou maquina que ajude… trabalhei 2 anos mexendo com bases de 100Gb, tabelas realmente enormes (não era java e o banco não era MySQL tb hehe)… programar alguma consulta sem usar um indice, o teu programa não chegava nem a ter a logica de negócio testada… corrigi vários problemas de performasse, e sempre o problema era na forma como foi programado…
meu conselho é vc ver certinho onde esta o erro, sera de maquina?! ou sera nas suas consultas e na definição do banco de dados?! se vc etstar no banco de dados os sql’s que a aplicação executa, demora muito tb?! não vou dizer com 100% certeza porque não conheço tantos BD, mas pesquisas com like ‘%…%’ ou propriedades que não tenham nenhum indice, geralmente vão ler a tabela toda, e ler tabelas grandes da problema idependente do banco…
outra coisa é utilizar paginação para fazer suas consultas… só que da maneira como esta sua aplicação, sem utilzar um framework de persistencia, sem seguir padrões… alterar tudo para suportar paginação e testar da um bom trabalho…
Kra… realmente, há um tempo atraz essa questão não era muito pensada aqui, mas conforme foi crescendo o sistema, começamos a verificar consultas pesadas, e a partir daí a estruturar melhor nossas consultas…
Quando vamos fazer uma pesquisa agora, trazemos apenas os campos realmente necessários, e estamos evitando também usar OR… LIKE ‘%%’, etc…
começamos também a usar otimização de sql em algumas consultas, e
temos indices no BD geralmente nos campos que usamos como parâmetros de consulta, mas mesmo assim, quando pesquisamos uma consulta grande diretamente no BD, a resposta é um pouco demorada… =\
O que percebemos é que qdo uma consulta é feita em várias tabelas, o MyISAM do mysql da um locked na tabela inteira… ai ela não pode ser acessada por outra consulta, atualização, etc…
Agora… paginação realmente temos poucas… ( da um trabalho danado fazer tudo na mão… rsrsrs… )
Mas se for o caso, creio que não vamos ter escapatória… hehehe…
Gostei deste tópico, estou trabalhando numa aplicação com porte parecido, e uma menor, mas tenho duvidas quanto ao pool de conexões, vou aproveitar este tópico para ver se alguem pode dar umas dicas.
Estou usando Struts e a persistencia atraves de DAO (acessando SQL Server 2005) com uma classe conectando atraves de um pool JNDI configurado no tomcat 5.0.28
A aplicação tem cerca de 40 usuarios conectados ao mesmo tempo (às vezes lendo informacoes, as vezes acessando o BD), mas acessando o banco de dados ao mesmo tempo talvez uns 10 no máximo.
Às vezes a aplicação “trava” no pool, excedendo o limite. Não faço idéia de qual a melhor forma de configurar.
So server.xml configurei a conexão com:
maxActive=50
maxIdle=10
maxWait=120000
estou no caminho ou tem coisa “feia” feita ai?
obs: Comecei a usar o Lambda Probe hoje, ainda não suguei nada de informação da aplicação.
