我在 Azure 中创建了我的第一个大型持久函数，它为文档的每一页运行大约 12 个活动函数。前几天我最多处理了 5000 页。我知道每个活动都会在工作项 Q 上放置一个项目，所以理论上我写了 60k 队列消息，这些消息也需要阅读，所以这是 120k 动作。
北欧 LRS GPv2 存储为 0.003 英镑/10K 类 2 Q 操作
所以这是 12 * £0.003 = 3.6p 但是我的订阅显示价值超过 90p 的 2 类 Q 操作，这相当于 3M Q 操作或每页 600 个 Q 操作。这大大超过了我在同一时期的消费计划的计算成本，即当天的 29 便士。我很感激还有其他消息需要进入 Q，但没想到这么多！
我是否遗漏了有关 Durable Functions 如何使用 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 操作，不知道为什么它需要轮询控制和工作项 Q什么都没有提交处理？）
在我看来，当函数实际执行操作时，会触发大量的 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 页面，因此当它们都过滤到存储帐户的指标时，我会看到指标的外观。
注意：查看图表，我注意到 13 日的数据似乎更合理，我不相信我改变了任何重要的东西，除了可能打开采样以获取应用洞察力，因为这会产生大量数据！
更新 2昨天在新的 v1 存储帐户上看到了同样巨大的 8k ish 页面处理数量。
