Apache工人之间的高消息延迟

Question

我正在与Apache玩一个实时图像处理应用程序，这需要超低延迟。在拓扑定义中，单个喷口每1s会发出原始图像(5MB)，几个螺栓将处理它们。每个螺栓的处理延迟是可以接受的，总的计算延迟可以在150 is左右。

然而，发现，不同节点上的工作人员之间的消息传递延迟确实很高。在连续5个螺栓上的总体延迟大约是200 is。为了计算这个延迟，我从端到端延迟减去所有的任务延迟。此外，我实现了一个计时器螺栓和其他处理螺栓将注册在这个计时器螺栓，以记录时间戳，然后开始真正的处理。通过比较螺栓的时间戳，我发现每个螺栓之间的延迟很高，正如我之前注意到的那样。

为了分析这种高附加时延的来源，我首先将发送间隔缩短到1s，因此由于计算开销高，所以不需要排队延迟。此外，从Storm，我发现没有螺栓是在高CPU利用率。

然后，我检查了网络延迟。我正在使用一个1 1Gbps的网络测试平台，通过RTT和带宽来测试网络。发送5MB图像的网络延迟不应该那么高。

最后，我正在考虑缓冲区延迟。我发现每个线程都维护自己的发送缓冲区，并将数据传输到工作人员的发送缓冲区。我不知道接收器螺栓需要多长时间才能收到这个发送信息。正如社区所建议的，我将发送方/接收方缓冲区大小增加到16384，将STORM_NETTY_MESSAGE_BATCH_SIZE修改为32768。然而，这并没有帮助。

我的问题是，如何消除/减少螺栓之间的消息开销？(内部工作人员)可以同步螺栓之间的通信，并使接收者立即收到发送的消息，而不是任何延迟。

Answer 1

对于低延迟，您可能需要调优netty缓冲区和传输批处理大小。其中一些延迟可能是由于当前工作人员的消息传递和线程模型所固有的。

此外，尝试调整干扰者吐露：

1. topology.disruptor.wait.timeout.millis
2. topology.disruptor.batch.size
3. topology.disruptor.batch.timeout.millis

尽管如此，社区正在努力通过重新设计消息子系统来提高延迟和吞吐量。请参阅https://github.com/apache/storm/pull/2502

Answer 2

通过将时间戳插入Storm源代码的详细基准测试，我发现在传递两个1440x1080图像时，“序列化”步骤占用的时间高达30‘s。如果我只将一个字节数组传递给一个元组，我认为这个步骤可以被删除，从而减少延迟.

Answer 3

根据您上面的评论，您将在每条消息中包含大约5MB的图像。

我不知道卡夫卡/风暴的细节，但我的理解是，它是一个主流的信息经纪人。这类系统的设计并不能处理大的有效载荷，主要是因为它们提供了关于传递和持久性的保证，这两种方法都需要某些处理步骤来缓冲字节流，在大多数情况下需要多次处理。这将使您的延迟时间随着大小的增加而有更大的线性时间增长。

我的建议是将您的图像存储在类似Couchbase或Memcached之类的东西中，然后发送一个包含指向它的指针的消息。这样的设置在一天之内就不会有困难了。