4

我已经看到了这个问题：两个独立的 Java 桌面应用程序之间的通信（答案：JGroups），我正在考虑使用 JavaGroups 或直接 RMI 来实现某些东西，但速度至关重要。我不会发送大量数据（MIDI 消息的内容，因此每个 3 个字节，不超过每三毫秒两条消息），这将全部在同一台机器上。认为同一台物理机器上的 RMI/JGroups 会很慢是愚蠢的吗？

（我的想法是我不能承受超过 1 毫秒的延迟，因为我已经有了一些延迟，但我不确定在这种情况下如何最好地谈论速度。）

我想我真正的问题是：Java 中的应用程序间通信有没有比 TCP/IP 更快的选项？我的意思是已经用 Java 实现的东西，而不是我需要实现的 JNI 可能性:)

我知道，不要及早优化所有这些，但也比抱歉更安全。

4

4 回答 4

6

Java中的应用程序间通信是否有任何比TCP/IP更快的选项？

不显着...... AFAIK。

但我认为你正在以错误的方式思考这个问题。假设您正在移动小消息，主要的性能杀手将是拨打电话的开销，而不是移动字节的速度。这些开销包括进行系统调用、在客户端和服务器端切换进程上下文、在内核中处理消息包头和路由数据包所花费的时间。并且任何同步的类似 RPC 的交互都需要进行调用以等待回复；即应用程序-> 服务器-> 往返时间。

获得更大吞吐量的方法是关注以下内容：

  • 减少应用程序所需的 RPC 数量；例如，通过将它们组合成更粗粒度，以及

  • 寻找将同步交互转变为异步交互的方法；例如，使用基于消息而不是基于 RPC 的技术。

于 2010-01-15T03:25:59.947 回答
2

如果速度至关重要，您应该在同一个线程中进行调用。使用网络您不会获得如此快的速度。

然而，假设速度不是那么重要，您可以在大约 500 微秒内执行 Java RMI 调用，并且使用自定义编码的 RPC，您可以在大约 24 微秒内通过环回进行调用。即使在同一 JVM 中的线程之间传递数据也可能需要 8 微秒。

您需要决定您愿意允许多少时间拨打网络电话。您还需要确定开始调用的时间是关键时间还是返回结果的时间。（通常后者有两倍的开销）

注意：我在这里说的是微秒，而不是毫秒。对于您的目的，我会忽略任何需要多毫秒的选项。

于 2010-01-15T23:48:49.673 回答
1

这个基准大约有两年的历史，但它表明唯一比 RMI 更快的流行 Java 远程解决方案是Hessian 2（我相信它仍处于测试阶段）。

但是，如果您的消息只有一位数字节，则使用任何远程解决方案似乎都过大了，特别是如果进程位于同一台机器上。如果可能的话，我建议将它们合并到一个进程中。您也可以考虑只使用普通的旧 Java 套接字。

于 2010-01-15T02:07:24.783 回答
0

认为同一台物理机器上的 RMI/JGroups 会很慢是愚蠢的吗？

如果您的机器不错，可能是的:) 如果您在一台有大量进程占用 CPU 等的机器上运行，那么情况可能会有所不同。与往常一样，确定您是否会遇到与我相同的事情的最佳方法是对其进行测试。

以下是在同一 JVM 中使用 nanoTime 使用 rmi 发送字符串“123”并在服务器上将其与“abc”连接以获取“123abc”并返回它所花费的时间（以毫秒为单位）。

冷 JVM：大约 0.25 毫秒延迟

0.250344
0.262695
0.241540
0.282461
0.301057
0.307938
0.282102

暖 JVM：大约 0.07 毫秒的延迟。

0.87916
0.72474
0.73399
0.64692
0.62488
0.59958
0.59814
0.66389

因此，如果 RMI 服务器和客户端在本地运行，您将在 1 毫秒内完成。

于 2018-07-17T02:02:15.313 回答