Queria compartilhar experiências sobre isso.
Achei umas dicas sobre como ter melhor desempenho com RMI. A mais interessante é zipar as informações trafegando na rede.
Alguem já implementou um servidor RMI para muitos clientes (100+)? Já teve problemas?
valeu!
Há uns 5 anos atrás não escalava para mais de 1500-2000 usuários.
Não sei como está agora…
Você precisa usar RMI diretamente, não pode utilizar EJBs? Ou um protocolo request/response como REST/SOAP/XML-RPC/Burlap/Hessian?
Qual o cenário?
Preciso de “respostas” assincronas (usando callbacks RMI)
Até poderiamos usar EJB(ida) + JMS(volta) mas acabamos escolhendo por algo mais simples (RMI puro) e porque outras aplicações aqui ja usam RMI também…
Até que eu soube que isso pode ter que atender muitos usuários… hehe…
Bom… mas se escala até 1500 usuários então ta bem tranquilo hehe… Mais por curiosidade agora… seria possivel escalar pra uns 5 mil?
A escalabilidade do RMI depende muito do workload e característica do teu sistema.
Primeiro que RMI é um protocolo super pesado, precisa de um name service, tem o DGC, usa serialização pra tudo e permite remote classloading, para começar. Ou seja, o mecanismo de marshaling é bem pesado.
Se o teu workload é de RPC com parâmetros e retorno pequenos, vale a pena sim usar, a escalabilidade é baixa-media, já que você vai acabar usando o modelo de thread-per-client, que não escala bem para mais de 500-600 clientes. Aqui temos máquinas que escalam até 3000, mas ela tem 10cpus e 8gigas de ram.
Caso teu workload tenha uma taxa de requisições alta ou troca de dados muito grandes, RMI deixa a desejar, principalmente por conta do overhead enorme importo pelo mecanismo de marshaling. Já vi tentarem usar RMI em um sistema que precisava atender um volume muito alto de requisições e simplesmente não escalou.
Moral da história, conheça teu workload e características do teu sistema primeiro, depois veja se compensa seguir com algo como RMI. Por exemplo, já escrevi/vi sistemas em Java que suporta 10mil conexões em máquinas xing-ling, mas eram totalmente bare-bones e nunca usavam thread-per-client.
Então acho que segui um bom caminho!
Eu preciso de muitos clientes conectados mas a troca de mensagens não é tao grande, o tamanho dos objetos também não é tão grande e o processamento não é muito pesado…
Até agora esta tudo ok. Fiquei preocupado com o futuro próximo mas acho que posso ficar sossegado por enquanto…
[quote=felipecruz]Então acho que segui um bom caminho!
Eu preciso de muitos clientes conectados mas a troca de mensagens não é tao grande, o tamanho dos objetos também não é tão grande e o processamento não é muito pesado…
Até agora esta tudo ok. Fiquei preocupado com o futuro próximo mas acho que posso ficar sossegado por enquanto…
[/quote]
Neste caso você deve fazer um pequeno protótipo para prova de conceito e submeter ele a carga planejada do sistema. Não fique no chutômetro.
Claro… mas até chegar a uns 100 usuários, vai demorar um pouco ainda…
Até la ja vai estar bem testado! hehe
valeu!
Por que vc precisa de respostas assíncronas?
Dá um exemplo prático ai!
Não sei se estou falando bobagem, mas as vezes respostas assíncronas, isto é, callbacks para os quais vc pode ter que esperar um tempo, podem ser facilmente obtidos sincronamente fazendo uma requisição ao servidor de N em N segundos.
São alertas que rodam no servidor e podem disparar a qualquer momento…
Os intervalos sao configurados pelos clientes…
Olá
[quote=felipecruz]Preciso de “respostas” assincronas (usando callbacks RMI)
Até poderiamos usar EJB(ida) + JMS(volta) mas acabamos escolhendo por algo mais simples (RMI puro) e porque outras aplicações aqui ja usam RMI também…
Até que eu soube que isso pode ter que atender muitos usuários… hehe…
Bom… mas se escala até 1500 usuários então ta bem tranquilo hehe… Mais por curiosidade agora… seria possivel escalar pra uns 5 mil?[/quote]
Respondendo bem atrasado…
JMS puro sem EJBs ou mesmo com EJBs é BEM mais simples do que RMI porque tudo que poderia ser um tiquinho complexo fica a cargo do servidor de mensagens.
[]s
Luca