linux - 使用进程间通信 (IPC) 的性能影响

Question

IPC 的用途是什么？是否可以使用 IPC 在进程之间发送更大的 JSON block (数百个字符)？我应该尝试使用 IPC 发送尽可能小的消息，还是通过减少消息大小获得的性能提升是否值得付出努力？

Answer 1

What type of usage is IPC intended for and is it is OK to send larger chunks of JSON (hundreds of characters) between processes using IPC?

从本质上讲，IPC 就是字面意思。当您需要在进程之间传递信息时(无论是什么)，它是一个可以使用的工具。该主题非常广泛，技术上包括分配共享内存和手动进行通信，但考虑到问题的基调和标签，我假设您在谈论操作系统提供的设施。

Wikipedia在讨论如何使用 IPC 方面做得很好，但我认为我不能做得更好，所以我将专注于第二个问题。

Should I be trying to send as tiny as message as possible using IPC or would the performance gains coming from reducing message size not be worth the effort?

这有点像微优化。我不能肯定地说，因为我不了解 Microsoft 和 Apple 的源代码，而且我真的不想深入了解 Linux 内核对 IPC 的实现，但是，这里有几点:

1. IPC 是一种常见操作，因此操作系统设计人员可能会对其进行优化以提高效率。有一些工程师团队已经考虑了这个问题并想出了如何让它更快。
2. 跨进程/线程通信的瓶颈几乎总是同步。延迟很糟糕，但竞争条件和死锁更糟。然而，由于系统控制着进程调度程序和内存管理器，因此操作系统设计人员可以通过许多创造性的方式来加快该过程。
3. 有很多方法可以加快数据传输速度。对于操作系统，如果数据需要跨越进程边界，那么可能需要进行一些复制，但操作系统一直在到处复制内存。考虑一个命令行实用程序，例如 netstat。当该可执行文件运行时，需要分配内存，需要从磁盘加载进程，并且在进程启动之前完成操作系统需要做的任何地址修复。这完成得如此之快，以至于你几乎没有注意到。在 Windows 上，netstat 大约为 40k，它几乎立即加载到内存中。 (记事本，另一个快速加载器的大小是它的 10 倍，但它仍然可以在很短的时间内启动。)
4. 上面#2 的一个大异常(exception)是，如果您在不在同一台计算机上的进程之间谈论 IPC。 (想想 Windows RPC)那么你真的会受到网络/通信堆栈速度的限制，但那时几 kb 在这里或那里不会产生很大的不同。 (您可以将 AJAX 视为 IPC 的一种形式，其中“进程”是服务器和您的浏览器。现在考虑一下 Google 文档的运行速度。)

如果 IPC 位于同一系统上的进程之间，我认为从您的消息中删除字节不值得付出大量努力。使您的消息易于调试。

如果通信发生在不同机器上的进程之间，那么您可能需要考虑一些事情，花费大量时间调试问题，如果使用更好的数据格式，多出几十毫秒，本来可以很简单传输时间不值得让数据更难解析/调试。记住三个优化规则¹:

1. 不要。
2. 不要……还没有。 (针对专家)
3. 在你做之前先介绍一下。

---

¹ 前两条规则通常归因于迈克尔 jackson 。 ( This one 不是 this one )