进程间通信是否能像进程内事件一样快（使用WCF和C#）

Question

我有一个应用程序，用于分析传入的事件流（CEP引擎）。这个流可以来自不同的源（数据库、网络等）。

为了有效地解耦，我希望该服务使用WCF公开一个命名管道，并允许另一个应用程序从源读取数据并将其提供给服务。因此，一个进程负责获取和处理传入的数据，而另一个进程负责分析它，两者使用WCF和命名管道绑定进行连接。它们都将部署在同一台机器上。

问题是，如果我将两个服务耦合到单个进程中并使用常规事件，那么在中间使用WCF是否会降低吞吐量？

- AltControl

---

不，IPC 永远不会像进程内事件处理一样快。但这是否在您的情况下真正重要，则是另一个问题。通常性能并不是您想要优化的内容。 - Cheeso

@cheeso 这个应用程序旨在处理每秒大量事件。因此，如果IPC瓶颈无法处理它，优化引擎以处理100,000个事件就毫无意义了。 - AltControl

我从你使用CEP这个术语推断出你需要高吞吐量。为了实现真正的可扩展性和可靠性，你需要依赖于多台计算机并进行横向扩展。这将意味着一定程度的IPC。在小规模（事件）上高效是很重要的，但你的整体顶级性能主要取决于你选择的扩展架构。WCF很好，因为它允许将构建块从本地机器移动到远程机器，具有灵活性。这是否对你重要，由你自己决定。 - Cheeso

@Cheeso：评论很好。如果有这样的信息，我会点赞一个答案。 - Jim Mischel

Answer 1

在现代主流操作系统中，IPC（进程间通信）永远不会像进程内事件处理一样快，也永远无法达到这种速度。原因是激活不同进程时上下文切换的开销。即使在多核系统中，不同进程在不同核心上运行，它们各自独立运行(因此激活一个进程与激活另一个进程没有成本 - 它们都始终处于活动状态)，跨进程的通信仍需要穿越安全边界、命中网络栈(即使使用管道)等。对于本地函数调用来说，调用需要大约1000个CPU周期，而IPC则需要数百万个周期。

因此，IPC比进程内通信要慢。但是否真正重要，在你的情况下是一个不同的问题。例如，假设你有一个需要蒙特卡罗模拟运行2小时的操作。在这种情况下，调用操作需要1毫秒或1000毫秒并不重要。

通常，你不想优化通信性能。即使性能很重要，专注于性能的一个小方面 - 比如是否使用IPC或本地函数调用 - 可能是错误的方法。

我认为"CEP"指的是"复杂事件处理"，这意味着高吞吐量、高容量处理。所以我理解性能对你很重要。

但是，为了真正的可扩展性和可靠性，你不能简单地优化进程内事件处理; 你需要依赖多台计算机进行扩展。这将意味着某种程度的IPC，无论如何都是必须的。在小规模(事件)上高效是非常重要的，但你整体的顶级性能主要受到你选择的架构的限制。

WCF很好，因为它允许你灵活地将构建块从本地机器移动到远程机器，并且由于通道堆栈，你可以以模块化的方式添加通信服务。

是否重要取决于你自己决定。

- Cheeso