进程间通信可以像进程内事件一样快(使用wcf和c#)

我有一个应用程序,对传入的事件流(CEP引擎)执行分析.此流程可以来自不同的来源(数据库,网络等).为了有效地解耦,我希望此服务使用wcf公开命名管道,并允许不同的应用程序从源读取数据并将其提供给服务.因此,一个进程...

我有一个应用程序,对传入的事件流(CEP引擎)执行分析.
此流程可以来自不同的来源(数据库,网络等).

为了有效地解耦,我希望此服务使用wcf公开命名管道,并允许不同的应用程序从源读取数据并将其提供给服务.

因此,一个进程负责获取和处理传入的数据,而另一个进程用于分析它,使用wcf和命名管道绑定将两者连接起来.它们都将部署在同一台机器上.

问题是,如果我将两个服务简单地耦合到一个进程并使用常规事件,我会注意到在中间使用wcf的吞吐量较低吗？

解决方法:

不,在现代主流操作系统中,IPC永远不会,也永远不会像进程中的事件一样快.其原因是与激活不同进程相关联的上下文切换的开销.即使对于不同进程在不同核心上运行的多核系统,尽管它们各自独立运行(因此没有与激活一个进程相关的成本与其他进程相关 – 它们都始终处于活动状态),跨进程的通信仍需要跨越安全性边界,击中网络堆栈(即使使用管道),等等.如果本地函数调用将在1000个cpu周期的数量级上调用,那么IPC将是数百万.

因此IPC将比进程内通信慢.这在你的案例中是否真的重要,是一个不同的问题.例如,假设您的操作需要运行2小时的蒙特卡罗模拟.在这种情况下,调用操作是否花费1ms或1000ms并不重要.

通常,通信的性能不是您想要优化的.即使性能很重要,关注性能的一个小方面 – 比方说,是否使用IPC或本地函数调用 – 可能是错误的方法.

我假设“CEP”被称为“复杂事件处理”,这意味着高吞吐量,高容量处理.所以我理解表现对你很重要.

但是,为了获得真正的可扩展性和可靠性,您不能简单地优化进程内事件;您将需要依赖多台计算机并向外扩展.这将意味着某种程度的IPC,无论如何.在较小规模(事件)中提高效率显然很重要,但您的整体高端性能将主要受您选择用于扩展的架构的限制.

WCF很好,因为它允许将构建块从本地计算机移动到远程计算机,并且由于通道堆栈,您可以以模块化方式添加通信服务.

这对您来说是否重要,取决于您自己决定.