RPC、套接字和性能注意事项

Posted 2023-02-16

【中文标题】RPC、套接字和性能注意事项

【英文标题】：RPC, sockets and performance considerations

【发布时间】：2011-05-10 18:46:21

【问题描述】：

我在同一个子网中有两台机器。我想尽快在两台机器之间交换对象。它使用 g++ 并且在 Debian/Ubuntu 上。机器负载在流量和 CPU 中。

一种方法是通过套接字作为二进制数据包发送对象的压缩序列化（使用 Google 协议缓冲区对 ex 进行编码）。

CORBA 似乎有点过头了

我看了一些关于 ONC-RPC 和 Sun RPC 的文章

Boost 是否为此提供了高效的库？

我相信您还有其他想法。您将如何保证 2011 年的最佳响应时间...我可以放弃一点点响应时间来获得标准解决方案。

【参考方案1】：

您可以将用于序列化的 Google protobuf 与 Boost.ASIO 结合起来处理实际的 I/O。这应该在性能和实施时间之间提供良好的平衡。

【参考方案2】：

Zeromq 人员已经尝试使用 Linux 实时内核来保证低延迟。正如你所看到的，为了这个保证，必须牺牲大量的平均延迟。根据应用程序，这可能是必要的权衡。

http://www.zeromq.org/results:rt-tests-v031

【讨论】：

+1 还没有准备好将我的内核更改为 LinuxRT。关于平均延迟与最差延迟的有趣观点。将研究 ZeroMQ

【参考方案3】：

当你说你想“尽可能快地在两台机器之间交换对象”时，听起来你感兴趣的是尽可能地限制网络带宽。如果是这种情况，您可以考虑使用FAST protocol。

首字母缩写词 FAST 的正式意思是“FIX Adapted for Streaming”，这意味着它最适合 FIX 协议，但事实并非如此。 FAST 可以用于任何协议。

FAST 编码的数据包可以非常小，一个好的实现将在编码和解码中使用有限的 CPU 资源。权衡是 FAST 协议并不是世界上最容易被人类理解的东西，而且要正确编写代码可能非常棘手。有可用的开源产品实现可能适合也可能不适合您的需求。一种这样的 C++ 实现是 QuickFAST。