具有持久功能的巨大的2级队列操作计数

Question

我在Azure中创建了我的第一个大型Durable函数，它为文档的每个页面运行大约12个活动函数。前几天我处理了最多5000页。我理解每个活动都会在工作项Q上放置一个项目，所以在理论上我写了60k队列消息，这些消息也需要被读取，以便进行120k的操作。

北欧LRS GPv2存储为£0.003 / 10K Class 2 Q action

所以这是12 *£0.003 = 3.6p但是我的订阅显示超过90p的Class 2 Q操作，因此相当于3M Q操作或每页600 Q操作。这大大超过我在同一时期消费计划中的计算成本，当天为29便士。我很欣赏还有其他消息需要进入Q但是并没有期待这么多！

我是否遗漏了耐久性功能如何使用Q的东西，是否有任何我可以注意或监控以尝试计算单个页面所生成的所有Q（成本）操作以便我可以工作如何减少它们。

欣赏任何见解，因为我喜欢耐用的功能，但存储成本开始变得令人望而却步！我将转向v1来削减成本，但仍然想了解这一点，以了解这是否只是功能的成本，或者我是否在我的功能中做了一些低效的事情。

更新3可能最有用

我创建了一个新版本，它只接受一个文件，一个活动将其拆分为单页pdf，然后每个页面由另一个活动处理以转换为png。 我创建了一个新的存储帐户并启用了每个日志记录选项并且日志记录被证明是最有用的，我上传了100页PDF然后当我下载并分析了该功能运行期间的日志时我看到了以下内容：

在10:31到10:43之间的大约处理，在此期间我从日志文件中看到：

203 PutMessage (which makes sense)
203 DeleteMessage

7868 GetMessage - all from the workitems queue

26445 GetMessages - all from the control queues, breakdown was
control-00 - 6217
control-01 - 6375
control-02 - 5134
control-03 - 8719

除此之外，我将应用程序闲置（在消费计划中），每小时我看到大约：

3500 - GetQueueMetadata - 700 against each Q, control 00-03 and workitems
3500 - PeekMessage - 700 against each Q, control 00-03 and workitems

（这里可能缺少最终日志，我认为它每10秒对每种类型的消息进行5个Q的轮询，因此每小时会有3600个Q动作，不知道为什么需要轮询控制和workitem Qs，如果没有提交任何处理？）

在我看来，当函数实际执行操作时会触发大量的GetMessage和GetMessages，查看日志，我可以提供日志，如果这有助于诊断问题。

（如果它是相关的，实例计数在完成时从0变为8，想知道实例与Q请求的丰富程度之间是否存在相关性）

更新1

所以我运行了以下内容，我希望能为我提供当天所有函数调用：

let start = datetime(2018-06-12T00:00:00);
traces
| where timestamp > start and timestamp < start + 24h
| where message startswith "function started" 
| summarize count()

这给了我总共19,939这是正确的，因为虽然有多个功能，但实际处理了大约3,500页的每个页面只调用了其中一些。

然后我设法找出如何查询该存储帐户上Q的指标，一旦我找到了过滤器，我发现以下是所有Q交易所在的地方：

看起来像一个荒谬的Q读数？只是为了检查我也看了，Q和25K上的消息量似乎大致正确：

我已经转移到V1存储帐户并尝试了另外一个大约8K页面的运行，因此当它们全部过滤到存储帐户的指标时，会看到指标的样子。

NB：看看图表，我注意到第13个数据似乎更明智，我不相信我改变了任何重要的事情，除了可能为app洞察力取样，因为这会产生大量数据！

更新2 昨天在新的v1存储帐户上查看了类似的8k页面处理数字。

Answer 1

只是队列的那个数量级似乎有点奇怪。

一般来说，每个活动函数调用将产生两个队列消息，一个用于请求，一个用于响应。还存在表存储操作和队列轮询操作的成本，但我假设您只关注此问题的队列消息？

有助于诊断的一件事是查看一切是否正确执行。您是否设置了Application Insights？请查看我们的Diagnostics documentation，了解如何使用Application Insights查询业务流程跟踪数据。具体来说，检查并查看您是否实际为每个文档执行12个活动功能，或者是否有其他可能导致这些成本极高的原因。

Answer 2

不确定是否继续前进。

持久性功能扩展中的bug was fixed似乎可以解释类似的行为。

如果尚未尝试，请尝试将其更新为v1.7。看看是否能解决问题。