c++ - 关于 RCF 中间件二进制大小

Question

RCF是用于 RPC 和分布式消息传递的库/框架。我喜欢RCF框架的原因如下

1. 在线服务 - 接口(interface) - rpc 调用规范(即，没有单独编译 IDL)。
2. C10K 设计风格(层叠在 windows IOCP 或 boost ASIO 之上)。
3. 支持 windows 命名管道和 unix 域套接字(我绝对不能在这方面妥协)。
4. SSL。
5. 消息传递范例，2 向、1 向、客户端回调、1 向批处理。
6. Protocol Buffer 支持(虽然我认为我可以坚持使用内置序列化)。
7. 发布/订阅功能。

我在 64 位 ubuntu 安装上使用 GCC 4.4.3。我在发行版的演示子目录中使用以下行编译了简单的服务器和客户端代码。

g++ -O3 -DRCF_USE_BOOST_ASIO Client.cpp ../src/RCF/RCF.cpp -I ../../Boost/-I ../include/-lpthread ../../Boost/lib/libboost_system.a -s

生成的客户端和服务器二进制文件在 1.7 到 2.2 兆字节之间波动。

警钟长鸣；我使用以下三个示例作为我的衡量标准:

1. Boost::ASIO:使用 bjam 在发布版本中编译的服务器 2 示例。剥离后的结果代码为 176kb。
2. nginx:一个高度复杂、高度可配置、非常高效的网络服务器。 500kb 剥离。
3. 专注于 Transport Channel 的最小中间件解决方案零 MQ。 libzmq 274k

我已经编写了自己的生产 RPC/中间件，我正处于一个阶段，我想我将只编写另一个来满足我的需求，在 Boost 之上分层。但我不想这样做。我喜欢RCF的设计，它符合我的需求。但是，我无法证明简单程序的二进制大小是合理的，它不应该产生如此庞大的二进制文件。

我主要担心两个问题。

1. rpc 代码路径的质量。我想要低延迟。
2. 当我开始围绕它编写我的应用程序时，二进制文件的增长。

一个合理的解释是该库不是为模块化而设计的，而是预先实例化所有内容。

[“问题”]

我想从设计实时数据处理系统的人那里得到一些关于我所关心的问题的反馈。你能证明这个尺寸合理吗？

["/问题"]

我会考虑替代方案。 ZMQ 很好，但它是一个额外的依赖项，缺少 SSL，不提供很多中间件原语，也不提供命名管道(我需要验证连接进程，命名管 Prop 有安全上下文)

Answer 1

您的命令行所做的是将 RCF 静态编译到服务器和客户端可执行文件中。这使得构建过程变得简单，但也意味着两个可执行文件都携带了它们自己的 RCF 拷贝。 RCF 1.3 中有超过 60000 行代码，因此它肯定会对可执行文件大小产生影响。

您可以将 RCF 构建到 DLL 中，然后链接到它。构建 DLL 时需要定义 RCF_BUILD_DLL，否则不会导出任何内容。

对于一个大概的数字，在我拥有的 Visual C++ 2008 构建环境中，这会产生一个 1.6 MB 的 DLL。仍然会有一些代码最终出现在导入模块中，因为 RCF 的编码代码使用模板，模板代码需要内联在 header 中，因此无法从 DLL 中导出。

关于您的顾虑:

(1) RCF 从一开始就以低延迟为设计理念，并且高度优化了远程调用的关键路径。例如，根本没有内存分配，也没有消息数据的复制。如果您担心，您可以编写一个简单的客户端和服务器，看看您每秒可以进行多少次调用(请记住使用发布版本)。有关更多信息，请查看 Performance User Guide 部分

(2) 与任何库一样，将其构建到应用程序中时会产生一些前期大小开销。但在那之后不会有任何“持续”的开销。