Pergunta

Eu vi a pergunta: Comunicação entre dois aplicativos de desktop Java separados (Resposta: JGroups) E estou pensando em implementar algo com JavaGroups ou RMI reto, mas a velocidade é essencial. Não estou enviando grandes quantidades de dados (conteúdo de mensagens MIDI, então 3 bytes cada, não mais do que duas mensagens a cada três milissegundos) e tudo isso estará na mesma máquina. É idiota pensar que o RMI/JGroups na mesma máquina física será lenta?

(Meu pensamento é que não posso pagar mais de 1 ms de latência, já que já tenho alguns, mas não tenho certeza de como falar melhor sobre velocidade nesse contexto.)

Eu acho que minha verdadeira pergunta é: Existem opções para a comunicação interap em Java que passam por algo mais rápido que o TCP/IP? Quero dizer, as coisas já implementadas em Java, não as possibilidades JNI que eu precisaria implementar :)

Eu sei, não otimize cedo e tudo isso, mas também mais seguro do que remediar.

Foi útil?

Solução

Existem opções para a comunicação interap em Java que passam por algo mais rápido que o TCP/IP?

Não é significativamente ... Afaik.

Mas acho que você está pensando nisso da maneira errada. Supondo que você esteja movendo pequenas mensagens, o principal assassino de desempenho será as despesas gerais de fazer uma chamada, e não a velocidade na qual os bytes são movidos. Essas despesas gerais incluem coisas como o tempo necessário para fazer chamadas do sistema, alternar os contextos de processo no lado do cliente e do servidor, para processar cabeçalhos de pacotes de mensagens dentro do kernel e rotear pacotes. E qualquer interação síncrona do tipo RPC implica fazer uma chamada de espera pela resposta; ou seja, o aplicativo -> servidor -> tempo de ida e volta.

A maneira de obter maior taxa de transferência é focar no seguinte:

  • reduzindo o número de RPCs que o aplicativo exige; por exemplo, combinando-os para serem mais grossos, e

  • procurando maneiras de transformar interações síncronas em interações assíncronas; por exemplo, usando a mensagem baseada em tecnologias baseadas em RPC.

Outras dicas

Se a velocidade for essencial, você deve fazer a chamada no mesmo thread. Você não será tão rápido quanto isso usando uma rede.

No entanto, assumir que a velocidade não é tão importante que você possa executar chamadas de Java RMI em cerca de 500 micro-segundos e usando RPC de codificação personalizada, você pode fazer chamadas em loopback em cerca de 24 micro-segundos. Mesmo a passagem de dados entre os threads na mesma JVM pode levar 8 micro-segundos.

Você precisa decidir quanto tempo está disposto a permitir fazer uma chamada de rede. Você também precisa decidir se o tempo para iniciar a chamada é fundamental ou o tempo para retornar um resultado. (Geralmente o último tem o dobro da sobrecarga)

NOTA: Estou falando de micro-segundo aqui, não mili segundos. Eu ignoraria quaisquer opções que levassem vários milissegundos para seus propósitos.

Este benchmark tem cerca de dois anos de idade, mas mostra que a única solução popular de Java Remoting mais rapidamente do que o RMI é Hessian 2(que ainda está na versão beta, acredito).

No entanto, se suas mensagens estiverem apenas em bytes de um dígito, o uso de qualquer solução remota parece um exagero, especialmente se os processos estiverem na mesma máquina. Eu recomendaria consolidá -los em um único processo, se possível. Você também pode considerar apenas usar órgãos java velhos e simples.

É idiota pensar que o RMI/JGroups na mesma máquina física será lenta?

Se sua máquina for decente provavelmente sim :) Se você estiver executando em uma máquina com toneladas de processos comendo CPU etc., as coisas poderão ser diferentes. Como sempre, a melhor maneira de descobrir se você experimentaria a mesma coisa que eu é testá -lo.

A seguir, é apresentado o tempo em milissegundos usando o nanotime na mesma JVM para enviar a string "123" usando o RMI e no servidor concatamos com "ABC" para obter "123ABC" e devolvê -lo.

JVM frio: aproximadamente 0,25 milissegundo latência

0.250344
0.262695
0.241540
0.282461
0.301057
0.307938
0.282102

JVM quente: aproximadamente 0,07 milissegundo latência.

0.87916
0.72474
0.73399
0.64692
0.62488
0.59958
0.59814
0.66389

Portanto, você ficaria bem em 1 milissegundo se o servidor RMI e o cliente estivessem em execução localmente.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top