哪个更好：发送许多小消息或更少的大消息？

Question

我有一个应用程序，其消息传递粒度可以用两种方式编写 - 发送许多小消息而不是（可能远）更少的大消息。从概念上讲，移动的是一组活着的＆＃39;可能基于顶点管理的已处理列表（顶点值）在每个超级步骤处过滤的顶点ID。幸存下来的是幸运的赢家。 compute()计算了一组“对我来说”的新内容。传入的ID非常适合传出消息，但我可以轻松地一次发送一个ID。我的猜测是发送更少的消息更重要，但随后每个集合可能包含数千个ID。谢谢。

P.S。一个侧面问题：我发现的几个自定义消息类型示例是相对简单的对象，具有一些原始实例变量，而不是集合。将一组ID作为信息发送是不是很疯狂？

Answer 1

我使用列表甚至地图发送或者只是存储为顶点数据，所以这不是问题。我认为你想选择的giraph并不重要，我宁愿选择许多简单的小消息，因为你会适当地使用Giraph。相反，您需要通过消息列表和通过ID列表的每条消息进入计算功能。

性能方面它不应该有任何区别。我发现产生重大影响的是，尝试尽可能多地计算周期，因为周期之间的切换和同步消息......需要花费大量时间。只要不改变它就应该或多或少相同，并且当你保持消息的大小很小时，可能更容易阅读和维护。

Answer 2

为了回答您的问题，您需要了解MessageStore界面及其实现。

简而言之，在引擎盖下，它采取了以下步骤：

1. 工作人员接收消息的字节原始输入和目标ID
2. 工作人员对消息进行排序并将其放入“地图的地图”中。第一个映射的键是分区ID，截面映射的键是顶点ID。 （它有点像邮局。工作就像中心枢纽，它先将字母分成不同的邮政编码，然后按地址排序每个邮政编码）
3. 当顶点转向计算时，该顶点消息的Iterable将传递给顶点的compute方法，这就是获取消息并使用它的地方。

因此，如果两种情况下的总字节数相同，则较少和较大的消息会更好，因为排序较少。

Answer 3

此外，您可以发送许多小消息，但让Giraph自动将其转换为长消息（几乎）。您可以使用Combiners。

关于这个主题的文档在Giraph网站上很糟糕，但你可以从书中Practical Graph Analytics with Apache Giraph中提取一个例子。

这主要取决于您发送的邮件类型。