Corba（例如 TAO）、Thrift、D-Bus、ICE 等框架的进程调用性能

Posted 2023-04-14

【中文标题】Corba（例如 TAO）、Thrift、D-Bus、ICE 等框架的进程调用性能

【英文标题】：In process call performance of frameworks like Corba (e.g. TAO), Thrift, D-Bus, ICE

【发布时间】：2013-05-24 08:31:25

【问题描述】：

我们正在尝试创建一个应用程序，它的一部分可能是分布式的，但不一定是分布式的。为此，我们想使用现有的远程调用框架。为了不重复实现所有内容，我们希望在同一台机器上的同一进程中使用相同的调用。

有谁知道使用这样的框架而不是直接调用 vtable 会导致性能/延迟损失？有比较吗？

系统应该在 Windows 和 Linux 上是可移植的

问候 托比亚斯

【问题讨论】：

看看zeromq.org，它们提供了一个有效的进程内通信和TCP通信抽象层。根据我的经验，它被证明是非常快的。我对 Corba 或 Thrift 的了解不够，无法比较性能。

【参考方案1】：

omniORB 长期以来一直有一个直接调用的协同定位快捷方式，但从版本 4 开始，它有一个专有的 POA 策略，可以绕过更多所需的 CORBA 行为，使其几乎与直接虚拟通话。请参阅omniORB Wiki 并搜索“快捷本地电话”。不幸的是，这似乎不在官方文档中，至少我能找到。

【讨论】：

omniORB 还在维护吗？上一个版本是几年前的。

是的。您可以订阅用户或开发者邮件列表并查看活动。

【参考方案2】：

据我所知，大多数通信框架的共同点是它们总是会序列化、发送和反序列化，这对于将引用传递给其他线程和直接访问数据（使用或不使用互斥锁）总是会造成性能影响.当明智地分配职责以尽量减少沟通时，这不应该总是很戏剧化。

请注意，对于这些架构选择，性能只是要考虑的方面之一。其他是：安全性、稳定性、灵活性、部署、可维护性、许可证等......

【讨论】：

是的，我知道。但是，如果性能不足以满足我们的用例，那么其余的就无关紧要了。我的问题是：开销有多“戏剧性”。

我的答案仍然存在：有序列化，所以会有开销，除非你找到一个框架保证在进程内使用时避免这种情况。我无法帮助对不同框架进行性能测试。

这就是为什么我问是否有人已经这样做了。顺便说一句，TAO 描述了这样的优化 - 但我还没有尝试过。

我使用了omniorb，它不使用套接字进行内部通信（我认为使用了管道），但仍然使用序列化。对于 TAO，这可能是相同的情况。对于 Corba，通信总是通过 IDL 接口完成，所以至少你必须填写这些数据......

ORBexpress 是 CORBA ORB 的另一个示例，它只是在处理过程中进行直接 C++ 调用。在这种情况下它不执行编组。

【参考方案3】：

来自ZeroMQ / Learn the basics：

2011 年，CERN（欧洲核研究组织）对 CORBA、Ice、Thrift、ZeroMQ、YAMI4、RTI 和 Qpid (AMQP) 进行了比较。 Read their analysis and conclusions。 (PDF)

这可能只是您所追求的比较。 （感谢 Matthieu Rouget 的评论。）

我也想指出，虽然某些 ORB 允许您跳过编组，但您仍然无法避免动态内存分配，这对性能来说非常重要。 （今天的 CPU 速度非常快，内存访问速度很慢，并且要求操作系统分配内存页面真的很慢。）

因此，在 C++ 中，您可能只返回 const string &，CORBA 的 C++ 绑定将强制您动态分配和释放字符串或数据结构（无论是通过返回类型还是输出参数）。如果方法跨进程/网络调用，这并不重要，但与普通 C++ 相比，在进程内它变得非常重要。

我们被烧毁的另一个“陷阱”是您不能定义相互递归的结构（即结构“A”包含一个“B”，它又包含一个“A”）。这意味着我们必须将它们转换为接口，它为每个结构分配一个 CORBA Servant“服务器端”（进程内），这非常占用内存。我收集了一些高级技巧来避免实际上创建仆人，但最终我们只想完全摆脱 CORBA，而不是更深入地挖掘自己。

尤其是在 C++ 中，内存管理非常脆弱，难以正确编程。 （参见The Rise and Fall or CORBA，“复杂性”部分。）我将许多人年的额外努力归功于这种技术选择。

我很想知道你是怎么相处的以及你采用了什么。

【参考方案4】：

创建 IBM 系统对象模型的几个原因之一是 CORBA。 IBM SOM 是“本地 CORBA”，而 IBM DSOM 是 CORBA 的实现。

你应该估计somFree。

另一个选项是UNO（来自 OpenOffice.org）。我不能说我喜欢UNO，它更糟糕，但它比早已被遗忘的SOM更成熟。 UNO 本地（进程内）生态系统根据编程语言分为多个分区。 C++ 和 Java 是最常见的分区。没有序列化，但分区间交互的首选机制是后期绑定（Java Proxy->Java Dispatch->C++ Dispatch->C++ object）（有点像 OLE 中的 IDispatch）虽然直接绑定也可以是 maid（Java Proxy-> C++ 对象）。

【参考方案5】：

当避免数据编组时，ZeroC 的 ICE 绝对支持搭配调用。您可以在他们的网站上找到有关文档的详细信息：http://doc.zeroc.com/display/Ice/Location+Transparency 虽然搭配调用与虚拟方法调用相比有一些开销，但不幸的是我没有实际数字，但这也取决于条件，即在特定适配器中注册了多少仆人等。