estou trabalhando em um sistema que processa varios tipos de arquivos, e faz varios tipos de processos nesses arquivos ou lotes de arquivos, alguns arquivos são até mesmo arquivos de outros tipos de bancos de dados, costumo abrir esses arquivos, faço varios tipos de validação nesses dados, extraio tudo para um SQL Server, até ai tudo bem, ja tive varios problemas de concorrência, problemas com o gerenciamento de conexões, ja que uso JDBC, os processos são muitos pesados, os clientes desse sistema chegam a enviar lotes com 200 mil arquivos dia, para processar isso deixo varias threads rodando, muitas threads, mas tenho pensado muito em melhorar o desempenho desse sistema, então estive dando uma olhada em RPC - Procedures Remotas, outro dia troquei uma idéia com um brother meu que é arquiteto e ativo aqui no forum e o mesmo me falou do Quartz, mas por não conhecer não sei se as funcionalidades do Quartz se aplica ao tipo de aplicação que tenho, então pergunto a vocês pelo que descrevi aqui desse sistema esses processos que hoje rodo com threads o que eu poderia usar que fosse de alto nivel para um sistema que é grande e extremamente complexo, o Quatz me parece servir mais para coisas agendadas que vão rodar depois, os processos do meu sistema rodam em seguida, alguns são concluidos em pouco tempo outros levam até horas, todo andamento desses processos é escrito em tabelas de logs e acessado pelos mesmos, por não ter um conhecimento avançado e lidar com um sistema de grande porte, não estou sabendo o que usar, do jeito que esta funciona bem até, mas procuro mais desempenho e quem ja trabalhou bastante com threads sabe que não é o melhor caminho, bem, obrigado desde ja qualquer ajuda é bem vinda, abraços.
[quote=pozzo]Na minha opinião, para saber aonde melhorar, você deve saber aonde é preciso melhorar. Por isso, use um profiler, encontre aonde estão os gargalos.
Sobre o Quartz, não acho que ajude no teu caso. Thread me parece ser mais adequado.[/quote]
meus gargalos são justamente as threads, queria usar outra solução algo mais robusto, e essas procedures remotas não se aplica ao caso ?
[quote=maior_abandonado]eu não sou nenhum expert no assunto, posso estar falando bestera mais… vc chegou a analisar colocar esses processos em arquivos em … EJBs?
não sei se intendi direito…[/quote]
a resposta é sim, mas a empresa que trabalho hoje tem uma arquitetura própria, e um framework próprio que eu mesmo ajudo no desenvolvimento, mas se for pensar em usar EJB ou não, no que isso implicaria ? aonde estão os ganhos ? o que facilitaria ? o que justificaria eu migrar de uma aplicação desse porte para o EJB ?
Bom, incialmente você poderia tentar usar um pool de conexões, para gerênciar melhor suas conexões com o banco de dados.
Também poderia verificar se as api de leitura de arquivos está sendo usada corretamente. Trocar algumas classes para nio, caso não esteja usando.
Outro ponto é que as vezes o teu hardware pode estar no limite. Talvez pensar em melhorar ele. Fazer um cluster, etc.
Eu siceramente não acredito que sejam as “Threads”, mas sim I/O dentro delas.
Sobre RPC, ou RMI (implementação Java), é para fazer computação distribuída. Talvez pensar em alguma implementação para distribuir esse processamento em várias máquinas, que é o caso do cluster que foi sugerido.
[quote=maior_abandonado]eu não sou nenhum expert no assunto, posso estar falando bestera mais… vc chegou a analisar colocar esses processos em arquivos em … EJBs?
não sei se intendi direito…[/quote]
O EJB seria uma opção, se fosse permitido ler arquivos com ele. A especificação diz que não se deve fazer isso, pois é o container deve gerênciar todos os recursos, acessos a dados, threads, etc.
[quote=pozzo][quote=maior_abandonado]eu não sou nenhum expert no assunto, posso estar falando bestera mais… vc chegou a analisar colocar esses processos em arquivos em … EJBs?
não sei se intendi direito…[/quote]
O EJB seria uma opção, se fosse permitido ler arquivos com ele. A especificação diz que não se deve fazer isso, pois é o container deve gerênciar todos os recursos, acessos a dados, threads, etc.[/quote]
bom… o que eu pensei quando citei EJB seria facilitar o controle de threads, você ter um pool de objetos para usar ao invés de ficar instanciando a medida que vai usar, eu não conheço essa parte, mas parece que EJB facilita um pouco a clusterização também.
Quanto a usar IO em EJBs, eu pensava que isso fosse desaconselhado, e não que fosse não permitido, acreditava que fosse desaconselhado pelo fato do servidor criar threads de acordo com a necessidade, então se essas threads acessarem arquivos, você não terá muito controle sobre quantas threads estarão ou não acessando algum arquivo em si, isso seria uma coisa a se levar em consideração e tomar certo cuidado com sincronização por exemplo…
[quote=maior_abandonado]bom… o que eu pensei quando citei EJB seria facilitar o controle de threads, você ter um pool de objetos para usar ao invés de ficar instanciando a medida que vai usar, eu não conheço essa parte, mas parece que EJB facilita um pouco a clusterização também.
Quanto a usar IO em EJBs, eu pensava que isso fosse desaconselhado, e não que fosse não permitido, acreditava que fosse desaconselhado pelo fato do servidor criar threads de acordo com a necessidade, então se essas threads acessarem arquivos, você não terá muito controle sobre quantas threads estarão ou não acessando algum arquivo em si, isso seria uma coisa a se levar em consideração e tomar certo cuidado com sincronização por exemplo…
[/quote]
Perfeito, as considerações sobre EJB estão corretas.
Quanto as restrições, você não deve fazer. Mas você consegue… O container pode ter mal funcionamento, é um risco que você vai correr.
[quote=maior_abandonado]bom… o que eu pensei quando citei EJB seria facilitar o controle de threads, você ter um pool de objetos para usar ao invés de ficar instanciando a medida que vai usar, eu não conheço essa parte, mas parece que EJB facilita um pouco a clusterização também.
Quanto a usar IO em EJBs, eu pensava que isso fosse desaconselhado, e não que fosse não permitido, acreditava que fosse desaconselhado pelo fato do servidor criar threads de acordo com a necessidade, então se essas threads acessarem arquivos, você não terá muito controle sobre quantas threads estarão ou não acessando algum arquivo em si, isso seria uma coisa a se levar em consideração e tomar certo cuidado com sincronização por exemplo…
[/quote]
eu acredito que possa facilitar a vida sim, quando se sabe bem EJB, que não é meu caso, não que eu tenha algum problema em aprender novas técnologias mas para eu alterar a técnologia de um sistema grande aqui na empresa que trabalho, teria eu que ter um bom argumento e ainda mostrar o que o EJB faz que a aplicação não faz hoje sem o uso dele, o que não consegui ver, eu ainda acredito que tenha outras opções alem da threads mas ainda não sei quais são. o problema de sincronização foi resolvido ja, o meu maior problema hoje ainda é com o SQL Server em fazer um delete cascade com referência na mesma tabela, usei outra solução, em 1 semana de teste uma das tabelas de log chegou a 2 giga mas isso é um outro rolo que vamos resolver colocando essas tabelas especifica por banco de dados, ja que são muitos bancos e hoje fica em um principal que todos outros bancos utilizam, queria eu entender de arquitetura a fundo para então dar o melhor nesse e em outros softwares, obrigado por responder amigo, abraços.
[quote=asaudate]Na verdade, vc tem várias opções interessantes:
JMS;
Spring Batch;
Apache Camel;
Só analisar os pontos de cada um e ver quais são interessantes para vc, OK?
[]´s[/quote]
obrigado, olhei a documentação dos 3 e o que mais se encaixa com o que procuro é o Spring Batch, vou ler a documentação a fundo e me certificar se vale a pena investir nele, antes de começar a migrar uma app grande, abraços velho, e obrigado.
Também não sou nenhum expert no assunto mas se o problema é a sobrecarga de dados na rede, já pensou em utilizar agentes ou agentes móveis?
Fiz um sistema (não profissional) em que utilizei agentes móveis e o resultado foi muito bom. Meu sistema tinha desempenho infinitamente melhor do que se eu utilizasse rpc pois as requisições na rede chegavam aos milhões. Acho que rpc em casos que existe possibilidade de ocorrer latência na rede nao é tão recomendado. Vale a pena dar uma olhada nos agentes, movéis ou não. Recomendo em Java, o Jade (mais profissional) e Aglets(mais fácil de implementar), porém existem outros e até em outras linguagens
Também não sou nenhum expert no assunto mas se o problema é a sobrecarga de dados na rede, já pensou em utilizar agentes ou agentes móveis?
Fiz um sistema (não profissional) em que utilizei agentes móveis e o resultado foi muito bom. Meu sistema tinha desempenho infinitamente melhor do que se eu utilizasse rpc pois as requisições na rede chegavam aos milhões. Acho que rpc em casos que existe possibilidade de ocorrer latência na rede nao é tão recomendado. Vale a pena dar uma olhada nos agentes, movéis ou não. Recomendo em Java, o Jade (mais profissional) e Aglets(mais fácil de implementar), porém existem outros e até em outras linguagens[/quote]
obrigado por responder amigo, meu problema maior até não é a sobrecarga, e sim as threads mesmo que não me soa bem usa-las, mas enfim vou dar uma olhada nesses agentes móveis pois desconheço o assunto, meu esquema é java mesmo, eu to estudando o Spring Batch que o amigo Asaudate citou acima, pelo que ja li dele parece se encaixar bem no sistema que estou trabalhando, final de semana ja devo implementar algo com ele, obrigado.