Fala pessoal,
Perceba que o seu metodo de salvar no banco esta synchronized(mutex), isso
quer dizer que esse método não sera executado em paralelo, algum motivo
especial para isso ?
Reforço a necessidade de realizar os testes de estresse! Enquanto eles
estiverem rolando, utilize o visualvm(ou algum outro aplicativo para
profiling java) para ver o comportamento das threads(se elas estão morrendo
normalmente), também acompanhe suas conexões com netstat -nab no windows ou
netstat -nap no linux.
Perceba que sua aplicação esta abrindo uma thread para cada requisição...
ou seja, você tem +- 8 requisições por segundo, em 1hr você teria 28800
threads... será que elas estão morrendo normalmente ? Será que os sockets
estão sendo finalizados realmente ? Tem que testar/monitorar/ajustar
código....
Por padrão no linux por exemplo, você normalmente tem um limite de 1024
arquivos para serem abertos... sugiro que você ajuste para 64000, da uma
olhada no ulimit e /etc/security/limits.conf, além disso existem as
limitações de file descriptors, mas acho que não será necessário.
Do que eu entendi da sua aplicação, faria o seguinte:
Fazer com que o sistema aceite por parâmetro um numero máximo de threads,
acredito que 10 seria o suficiente. O resto das requisições entrariam em
uma fila(isso, quando necessário), dessa forma você teria um pool de
threads de até 10 threads(assim você irá aliviar o GB e o sistema
operacional)... Utilizaria singleton para conexão com o banco de dados e
não deixaria a requisição com o banco synchronized(mutex).
[]s
--
Att, Marcelo M. Fleury
Blog - http://marcelomf.blogspot.com/
Slides - http://www.slideshare.net/marcelomf/
"O primeiro dever da inteligência é desconfiar dela mesma." By Einstein
[As partes desta mensagem que não continham texto foram removidas]
Para upload/download de arquivos: http://www.yahoogroups.com/files/java-br
0 comentários:
Postar um comentário