私は質問を見ました：2つの別々のJavaデスクトップアプリケーション間の通信（答え：JGroups）そして私はJavaGroupsまたはストレートRMIで何かを実装することを考えていますが、速度が重要です。私は大量のデータを送信していません（MIDIメッセージのコンテンツなので、それぞれ3バイト、3ミリ秒ごとに2つのメッセージしか送信しません）。これはすべて同じマシン上にあります。同じ物理マシン上のRMI/JGroupsが遅くなると考えるのは賢明ですか？
（私の考えでは、すでにいくつかのレイテンシーがあるため、1ミリ秒を超えるレイテンシーを許容することはできませんが、このコンテキストで速度について最もよく話す方法がわかりません。）
私の本当の質問は、JavaでTCP / IPよりも高速なものを経由するアプリ間通信のオプションはありますか？つまり、実装する必要のあるJNIの可能性ではなく、Javaですでに実装されているものです:)
私は知っています、早い段階で最適化しないでください、しかしまた後悔するより安全です。
TCP / IPよりも高速なJavaでのアプリ間通信のオプションはありますか？
それほど重要ではありません...AFAIK。
しかし、私はあなたがこれについて間違った方法で考えていると思います。小さなメッセージを移動していると仮定すると、パフォーマンスの主なキラーは、バイトの移動速度ではなく、呼び出しを行うオーバーヘッドになります。これらのオーバーヘッドには、システムコールの実行、クライアント側とサーバー側でのプロセスコンテキストの切り替え、カーネル内のメッセージパケットヘッダーの処理、パケットのルーティングにかかる時間などが含まれます。また、同期RPCのような対話では、応答を待つために呼び出しを行う必要があります。つまり、アプリ->サーバー->ラウンドトリップ時間です。
スループットを向上させる方法は、次のことに焦点を当てることです。
アプリケーションが必要とするRPCの数を減らす。たとえば、それらを組み合わせてより粗くすることによって、
同期相互作用を非同期相互作用に変える方法を検討する。たとえば、RPCベースのテクノロジーではなくメッセージベースのテクノロジーを使用します。
速度が重要な場合は、同じスレッドで呼び出しを行う必要があります。ネットワークを使用すると、これほど速くはなりません。
ただし、速度がそれほど重要ではないと仮定すると、約 500 マイクロ秒で Java RMI 呼び出しを実行でき、カスタム コード RPC を使用すると、ループバック経由で約 24 マイクロ秒で呼び出しを行うことができます。同じ JVM 内のスレッド間でデータを渡す場合でも、8 マイクロ秒かかることがあります。
ネットワーク コールを発信できる時間を決定する必要があります。また、通話を開始する時間が重要なのか、それとも結果を返す時間が重要なのかを判断する必要があります。(多くの場合、後者はオーバーヘッドが 2 倍になります)
注: ここでは、ミリ秒ではなく、マイクロ秒について話しています。あなたの目的のために数ミリ秒かかるオプションは無視します。
このベンチマークは約2年前のものですが、RMIよりも高速なJavaリモーティングソリューションとして人気があるのはHessian 2（まだベータ版だと思います） だけであることを示しています。
ただし、メッセージが1桁のバイトしかない場合、特にプロセスが同じマシン上にある場合は、リモートソリューションを使用するのはやり過ぎのように思われます。可能であれば、それらを単一のプロセスに統合することをお勧めします。また、単純な古いJavaソケットの使用を検討することもできます。