C# Azure WebJob通过ICollector将消息输出到队列的列表似乎很慢

我有一个Azure WebJob，它在文件的页面中循环并处理它们。该作业还有一个到输出队列的ICollector：

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

---

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

慢与快之间没有客观标准，但有一些想法：

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

b） 我知道您提到在处理完所有文件行之前无法写入队列，但是如果可能的话，您可能会重新考虑这个选择。如果您可以并行处理文件中的行以及随后写入输出队列（使用多个WebJob实例或单个WebJob实例中的TPL任务），那么您可能会更快地完成这项工作。再一次，我意识到你在前面说你不能这么做，所以我建议你考虑这个选择的全部含义（如果你还没有）。 c） 另一种可能是。。。确保存储队列所在的区域与WebJob所在的区域相同，以最小化延迟

---

祝你好运

谢谢你的意见，乔希。我的QueueMessageBatchPage POCO类很小，有4个属性（2个整数，2个字符串）。我已经尝试过并行处理，将PDF分解成多个页面，然后用另一个作业分别处理每个页面。因为我必须准备好输入PDF的每一页并将其光栅化，所以我不知道如何进一步细分这个初始过程。我所有的azure资源都在美国西部。嗨，布莱恩。。。所以我很好奇，决定尝试一个快速的演示来模拟你的情况，看看我发现了什么。我编写了一个小WebJob，从队列消息触发并获取一个大blob，然后将其分解为写回存储的较小blob，每个blob都有一个对应的输出消息到另一个队列。我用文本文件代替PDF。。。长话短说，整个事情很快。当然，数据的内容和大小可能与您的情况非常不同。请随便看一看，看看是否有帮助。哇，谢谢你的额外努力。我想我需要做进一步的测试来确定减速的原因。但这很奇怪，我在foreach outputMessages循环前后使用了秒表计时器，测量了300条消息的50多秒。我看到您在测试中使用了Azure Storage 6.0.2。我以为WebJobs SDK团队将依赖限制设置为5.0.2，所以我还没有升级。我不知道这是否会起作用。

List<QueueMessageBatchPage>

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