【问题标题】:Azure WebJob Output List of Messages to Queue via ICollector seems slow通过 ICollector 向队列发送消息的 Azure WebJob 输出列表似乎很慢
【发布时间】:2016-03-25 08:17:45
【问题描述】:

我有一个 Azure WebJob 循环遍历文件页面并处理它们。该作业还有一个输出队列的 ICollector:

[Queue("batch-pages-to-process")] ICollector<QueueMessageBatchPage> outputQueueMessage

在将所有内容发送到输出队列之前,我需要等到所有页面都处理完毕,因此我没有在文件处理循环中将每条消息添加到 ICollector,而是将消息添加到队列消息列表中:

List<QueueMessageBatchPage>

处理完所有页面后,我会遍历列表并将消息添加到 ICollector:

foreach (var m in outputMessages)
{
    outputQueueMessage.Add(m);
}

但最后一部分似乎需要很长时间。要添加 300 条队列消息,大约需要 50 秒。我没有太多可以衡量的,但这似乎很慢。这正常吗?

【问题讨论】:

    标签: c# azure azure-webjobs azure-webjobssdk


    【解决方案1】:

    没有慢与快的客观标准可以提供给您,但有一些想法:

    a) 排队时间的一部分将是每个 QueueMessageBatchPage 实例的序列化...其性能将与这些实例所代表的对象图的广度和深度成反比。更多的数据显然需要更多的时间来写入队列。

    b) 我知道您提到在处理完所有文件行之前您不能写入队列,但如果可能的话,您可能会重新考虑该选择。在某种程度上,您可以并行处理文件中的行以及随后写入输出队列(使用多个 WebJob 实例或可能在单个 WebJob 实例中使用 TPL 任务),您可能会更快地完成这项工作。再一次,我意识到你事先声明你不能这样做,所以我只是建议你考虑这个选择的全部含义(如果你还没有的话)。

    c) 另一种可能的方法...确保您的存储队列所在的区域与您的 WebJob 所在的区域相同,以最大限度地减少延迟。

    祝你好运!

    【讨论】:

    • 感谢乔希您的意见。我的 QueueMessageBatchPage POCO 类很小,有 4 个属性(2 个整数,2 个字符串)。我已经尝试通过将 PDF 分成页面然后将每个页面与另一个作​​业分开处理来并行化处理。因为我必须准备好输入 PDF 的每一页并对其进行光栅化,所以我不确定如何进一步分解这个初始过程。我所有的 azure 资源都在美国西部。
    • 嗨 Bryan... 所以我很好奇并决定尝试一个快速演示来模拟您的情况,看看我发现了什么。我编写了一个小的 WebJob 来从队列消息中触发并抓取一个大 blob,然后将其分解成较小的 blob,并写回存储中,每个 blob 都有一个对应的输出消息到另一个队列。我使用文本文件而不是 PDF……长话短说,整个过程非常快。当然,数据内容和大小可能与您的情况有很大不同。随意看看,看看它是否有帮助。 github.com/jplane/SO.WebJob.Demo
    • 哇,感谢您的额外努力。我想我需要做进一步的测试来确定减速可能来自哪里。不过这很奇怪,我在 foreach outputMessages 循环之前和之后使用了一个秒表计时器,它测量了 300 条消息的 50 多秒。我看到您在测试中使用了 Azure Storage 6.0.2。我以为 WebJobs SDK 团队将依赖限制设置为 5.0.2,所以我没有升级。我想知道这是否正在发挥作用。
    猜你喜欢
    • 1970-01-01
    • 2017-04-27
    • 2017-09-14
    • 2014-01-28
    • 1970-01-01
    • 2012-10-20
    • 1970-01-01
    • 2014-02-01
    • 1970-01-01
    相关资源
    最近更新 更多