我正在使用Apache Storm进行实时图像处理应用程序，这需要超低延迟。在拓扑定义中，单个喷口将每1秒发出一次原始图像（5MB），并且一些螺栓将处理它们。每个螺栓的处理延迟是可以接受的，整体计算延迟可以是大约150ms。
但是，我发现不同节点上的工作者之间的消息传递延迟非常高。 5个连续螺栓的总延迟时间约为200ms。为计算此延迟，我从端到端延迟中减去所有任务延迟。此外，我实现了一个计时器螺栓和其他处理螺栓将在此计时器螺栓中注册，以记录开始实际处理之前的时间戳。通过比较螺栓的时间戳，我发现每个螺栓之间的延迟很高，正如我之前注意到的那样。
为了分析这个高附加延迟的来源，我首先将发送间隔减少到1秒，因此由于高计算开销而不应该有排队延迟。此外，从Storm UI，我发现没有任何螺栓处于高CPU利用率。
然后，我检查了网络延迟。我正在使用1Gbps网络测试平台，并通过RTT和带宽测试网络。发送5MB图像的网络延迟不应该那么高。
最后，我在考虑缓冲延迟。我发现每个线程都维护自己的发送缓冲区并将数据传输到工作人员的发送缓冲区。我不确定接收器螺栓能够获得此发送消息需要多长时间。根据社区的建议，我将发送方/接收方缓冲区大小增加到16384，将STORM_NETTY_MESSAGE_BATCH_SIZE修改为32768.但是，它没有帮助。
我的问题是如何删除/减少螺栓之间的消息传递开销？（内部工作人员）可以同步螺栓之间的通信并使接收器立即获得发送消息而不会有任何延迟？
答案 0 :(得分：0)
对于低延迟，您可能需要调整netty缓冲区并传输批量大小。由于当前工作人员的消息传递和线程模型，其中一些延迟可能是固有的。
同时尝试调整破坏者配置：
据说社区正在努力通过重新设计消息传递子系统来改善延迟和吞吐量。见https://github.com/apache/storm/pull/2502
答案 1 :(得分：0)
通过在Storm的源代码中插入时间戳的详细基准测试，我找到了步骤＆＃34;序列化＆＃34;通过两张1440x1080图像时，最多需要30ms。如果我纯粹将字节数组传递给元组，我认为可以删除此步骤，从而减少延迟......
答案 2 :(得分：0)
根据您上面的评论，您在每封邮件中包含大约5MB的图片。
我不太了解kafka / storm，但我的理解是它是主流的消息经纪人。这样的系统不是为处理大的有效载荷而设计的，主要是由于它们提供了关于传送和持久性的保证，这两者都需要在大多数情况下多次缓冲字节流的某些处理步骤。随着大小的增加，这会使您的延迟时间增长超过线性时间。
我的建议是将图像存储在像Couchbase或Memcached这样的快速内容中，然后发送包含指向它的指针的消息。这样的设置不难在一天之内起床和运行。