Java TCP/IP 套接字延迟 - 停留在 50 μs(微秒)？ (用于 Java IPC)

Question

我们一直在分析和分析我们的应用程序，以尽可能减少延迟。我们的应用程序由 3 个独立的 Java 进程组成，它们都在同一台服务器上运行，它们通过 TCP/IP 套接字相互传递消息。

我们已将第一个组件的处理时间减少到 25 微秒，但我们发现 TCP/IP 套接字写入(在本地主机上)到下一个组件总是需要大约 50 微秒。我们看到了另一种异常行为，因为接受连接的组件可以更快地写入(即 < 50 μs)。现在，除套接字通信外，所有组件的运行时间都小于 100 微秒。

不是 TCP/IP 专家，我不知道可以做些什么来加快速度。 Unix 域套接字会更快吗？内存映射文件？还有哪些其他机制可能是将数据从一个 Java 进程传递到另一个进程的更快方法？

2011 年 6 月 21 日更新我们创建了 2 个基准应用程序，一个用 Java，一个用 C++ 来更严格地对 TCP/IP 进行基准测试并进行比较。 Java 应用程序使用 NIO(阻塞模式)，而 C++ 使用 Boost ASIO tcp 库。结果大致相同，C++ 应用程序比 Java 快大约 4 微秒(但在其中一项测试中，Java 击败了 C++)。此外，这两个版本在每条消息的时间上都表现出很大的差异。

我认为我们同意共享内存实现速度最快的基本结论。 (虽然我们也想评估 Informatica 产品，但前提是它符合预算。)

Answer 1

如果使用 native 库 via JNI是一个选项，我会考虑照常实现 IPC(搜索 IPC、mmap、shm_open 等)。

使用 JNI 会带来很多开销，但至少比使用套接字或管道执行任何操作所需的完整系统调用要少一些。通过 JNI 使用轮询共享内存 IPC 实现，您可能能够将单向延迟降低到大约 3 微秒。 (确保使用 -Xcomp JVM 选项或调整编译阈值；否则您的前 10,000 个样本会很糟糕。这会产生很大的不同。)

我有点惊讶 TCP 套接字写入需要 50 微秒 - 大多数操作系统在某种程度上优化了 TCP 环回。 Solaris 实际上用一个叫做 TCP Fusion 的东西做得很好。 .如果对环回通信进行了任何优化，那通常是针对 TCP。 UDP 往往会被忽视——所以在这种情况下我不会为它烦恼。我也不会为管道(标准输入/标准输出或您自己的命名管道等)而烦恼，因为它们会更慢。

通常，您看到的很多延迟可能来自信号 - 在套接字的情况下等待 IO 选择器(如 select())，或等待信号量，或等待某些东西。如果你想要尽可能低的延迟，你将不得不燃烧一个核心，坐在一个紧密的循环轮询中以获取新数据。

当然，总有 commercial off-the-shelf路线——我碰巧知道肯定会很快解决你的问题——但当然它确实要花钱。为了全面披露:我确实为 Informatica 工作，开发他们的低延迟消息传递软件。 (作为一名工程师，我的诚实意见是它是非常棒的软件 - 当然值得为这个项目检查。)