É comum usuários do ERP da CMNet Soluções (3 camadas) se depararem com problemas de performance, travamentos e crash do Borland Socket Server.
A questão é que o fornecedor do ERP implementou uma funcionalidade em seus clients, permitindo ao usuário final indicar em qual app server deseja se conectar, o que compromete a definição de responsabilidades da arquitetura da solução em questão.
Após sofrer com o completo desbalanceamento e consequente aumento de crashes nos horários mais "insanos" possíveis e salvos pelo Network Load Balance (5 app servers balanceados), desenvolvemos o programa Java "LoadSocket", que recebe informações do estado de cada app server, reestabelecendo o serviço que sofreu crash, garantindo 100% de disponibilidade do ambiente, qualidade do balanceamento de carga entre os app servers e, lógico, o retorno à vida normal, sem a necessidade de ser acordado durante seguidas madrugadas.
Porém, um problema ainda persiste, a baixa performance do Borland Socket Server com o ambiente da CM, ou seja, cada servidor consegue atender com eficiência, entre 40 e 50 conexões simultãneas, independentemente do hardware envolvido.
Neste contexto, estamos concluindo o desenvolvimento de um Socket Server Java, que utiliza-se de threads para ampliar o desempenho do ambiente. Logicamente, ao contrário da solução da Borland, esta implementação exigirá bem mais do hardware servidor. O ganho de performance esperado (segundo testes com versão beta) está em torno de 50 a 70% e deverá tornar a vida do administrador do ambiente bem mais fácil, a partir de interações automatizadas, via mensagens de e-Mail e SMS e outros recursos configuráveis.
Eloir Cortes
Assinar:
Postar comentários (Atom)
3 comentários:
Cara, uma solução interessante tb seria usar o Java NIO para gerenciamento de conexões, ao invés de criar uma thread por conexão. Existem uns projetos que oferecem uma abstração para facilitar o desenvolvimento com NIO (que não é dos mais fáceis). Dá uma olhada no Grizzly (https://grizzly.dev.java.net/) do pessoal do glassfish.
Para ter uma idéia do ganho de performance dá uma olhada nesse links
http://72.14.205.104/search?q=cache:zrIVD2u0lbgJ:blog.covalent.net/roller/covalent/entry/20070308&safe=images
http://weblogs.java.net/blog/jfarcand/archive/2006/03/can_a_grizzly_r.html
André, obrigado pela dica.
Eu já dei uma lida sobre NIO, quando a Java Magazine fez uma matéria sobre o tema, se não me engano.
Pretendo retomar o assunto, pois estou buscando facilidade no gerenciamento de conexões, aliado ao poder do paralelismo.
Grande POST, Obgd.. já não me sinto sozinho nesta luta!
Postar um comentário