RMI 有多快？
我看到了这个问题：两个单独的Java桌面应用程序之间的通信（答案：JGroups），我正在考虑使用 JavaGroups 或直接 RMI 来实现一些东西，但速度至关重要。我不会发送大量数据（MIDI 消息的内容，因此每个 3 个字节，每三毫秒不超过两条消息），并且这些数据都将在同一台机器上。 认为同一台物理机器上的 RMI/JGroups 会很慢是愚蠢的吗？
（我的想法是我无法承受超过 1 毫秒的延迟，因为我已经有了一些延迟，但是我不确定在这种情况下如何最好地谈论速度。）
我想我真正的问题是：Java 中的应用程序间通信是否有任何比 TCP/IP 更快的选项？我意味着已经用 Java 实现的东西，而不是我需要实现的 JNI 可能性:)
我知道，不要过早优化等等，但安全总比后悔好。
I have seen the question: Communication between two separate Java desktop applications (answer: JGroups) and I'm thinking about implementing something with JavaGroups or straight RMI but speed is of the essence. I'm not sending large amounts of data around (content of MIDI Messages, so 3 bytes each, no more than say two messages every three milliseconds) and this will be all on the same machine. Is it daft to think that RMI/JGroups on the same physical machine will be slow?
(My thought is that I can't afford more than 1ms of latency, since I've already got some, but I'm not sure how to best talk about speed in this context.)
I guess my real question is: are there any options for interapp communication in Java that go through something FASTER than TCP/IP? I mean things already implemented in Java, not JNI possibilities that I'd need to implement :)
I know, don't optimize early and all that, but also better safe than sorry.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
不显着......据我所知。
但我认为你思考这个问题的方式是错误的。假设您正在移动小消息，主要的性能杀手将是进行调用的开销，而不是移动字节的速度。这些开销包括进行系统调用、在客户端和服务器端切换进程上下文、在内核中处理消息数据包标头以及路由数据包所花费的时间。任何类似 RPC 的同步交互都需要进行调用并等待回复；即应用程序->服务器->往返时间。
获得更大吞吐量的方法是关注以下方面：
减少应用程序所需的 RPC 数量；例如，将它们组合得更粗粒度，并
Not significantly ... AFAIK.
But I think you are thinking about this the wrong way. Assuming that you are moving small messages, the main performance killer will be the overheads of making a call rather than the speed at which bytes are moved. These overheads include such things as the time taken to make system calls, to switch process contexts on the client and server side, to process message packet headers within the kernel and to route packets. And any synchronous RPC-like interaction entails making a call an waiting for the reply; i.e. the app -> server -> round trip time.
The way to get greater throughput is to focus on the following:
reducing the number of RPCs that the application requires; e.g. by combining them to be more coarse-grained, and
looking at ways to turn synchronous interactions into asynchronous interactions; e.g. using message based rather than RPC based technologies.
这个基准测试已有大约两年的历史，但是它表明，唯一比 RMI 更快的流行 Java 远程解决方案是 Hessian 2（我相信它仍处于测试阶段） ）。
但是，如果您的消息仅采用个位数字节，那么使用任何远程处理解决方案似乎都有些矫枉过正，尤其是当进程位于同一台计算机上时。如果可能的话，我建议将它们合并到一个流程中。您还可以考虑仅使用普通旧式 Java 套接字。
This benchmark is about two years old, but it shows that the only popular Java remoting solution faster than RMI is Hessian 2(which is still in beta I believe).
However if your messages are only in single digit bytes, using any remoting solution seems like overkill, especially if the processes are on the same machine. I'd recommend consolidating them into a single process if possible. You could also consider just using plain old Java sockets.
如果速度至关重要，您应该在同一线程中进行调用。使用网络您不会获得如此快的速度。
然而，假设速度不是那么重要，您可以在大约 500 微秒内执行 Java RMI 调用，并且使用自定义编码的 RPC，您可以在大约 24 微秒内通过环回进行调用。即使在同一 JVM 中的线程之间传递数据也可能需要 8 微秒。
您需要决定愿意留出多少时间来进行网络呼叫。您还需要决定开始调用的时间或返回结果的时间是否重要。 （通常后者的开销会增加一倍）
注意：我这里说的是微秒，而不是毫秒。我会忽略任何需要花费几毫秒才能达到您目的的选项。
If speed is of the essence, you should make the call in the same thread. You won't get as fast as this using a network.
However, assuming speed is not quite that important you can perform Java RMI calls in about 500 micro-seconds and using custom coded RPC you can make calls over loopback in about 24 micro-seconds. Even passing data between threads in the same JVM can take 8 micro-seconds.
You need to decide how much time you are willing to allow to place a network call. You also need to decide if the time to start the call is critical or the time to return a result. (Often the latter has double the overhead)
Note: I am talking micro-second here, not milli-seconds. I would ignore any options which take multiple milliseconds for your purposes.
如果你的机器性能不错，可能是的:)如果你运行的机器上有大量进程占用 CPU 等，那么情况可能会有所不同。与往常一样，了解您是否会经历与我相同的事情的最佳方法就是进行测试。
以下是在同一 JVM 中使用 nanoTime 所花费的时间（以毫秒为单位）
使用 rmi 发送字符串“123”，并在服务器上将其与“abc”连接以获得
“123abc”并返回。
冷 JVM：约 0.25 毫秒延迟
热 JVM：约 0.07 毫秒延迟。
因此，如果 RMI 服务器和客户端在本地运行，那么您的时间将在 1 毫秒之内。
If your machine is decent probably yes :) If you're running on a machine with tons of processes eating CPU etc then things might be different. As always the best way to find out if you would experience the same thing as me is to test it.
The following is the time in milliseconds taken using nanoTime in the same JVM
to send the string "123" using rmi and on the server concat it with "abc" to get
"123abc" and return it.
Cold JVM: Approximately 0.25 millisecond latency
Warm JVM: Approx 0.07 millisecond latency.
So you would be well within 1 millisecond if the RMI server and client is running locally.