在 App Service Plan 上运行的 Durable Functions 性能低下？

Question

我正在 App Service Plan 上测试 Durable Functions，因为我的一些活动将运行 +20 分钟，我现在不想支付 Premium。

工作流程本质上是这样的：

• 从第三方服务获取更新列表（ID，通常在 20-30k 左右）
• 对于所有 ID，以一个 ID 作为输入调用另一个活动函数（并行）
• 汇总所有结果并从编排器返回

这运行得很慢。 此工作流程当前作为 WebJob 在产品中运行。 对于我们的一个集成，它按顺序循环遍历每个 ID，大约需要 20 分钟才能完成。 使用 Durable Functions，它使用 40 分钟。 怎么会这样呢？ 因为它并行处理每个 ID，所以它不应该运行得更快吗？ 我知道后台所有队列都有开销，但真的会这么慢吗？

增加它可以运行的活动量会有帮助吗？ 我看到运行此工作流程时应用程序计划的 CPU% 为 100%，所以我不确定。

按 B2 计划运行。

如果有人在应用程序计划中使用 DF 有任何提示或经验，我将不胜感激任何反馈！

使用 host.json 更新：

{
  "version": "2.0",
  "logging": {
    "logLevel": {
      "default": "Information",
      "Host.Results": "Information",
      "Function": "Information",
      "Host.Aggregator": "Information"
    }
  },
  "extensions": {
    "durableTask": {
      "maxConcurrentActivityFunctions": 200,
      "maxConcurrentOrchestratorFunctions": 100,
      "extendedSessionsEnabled": true,
      "extendedSessionIdleTimeoutInSeconds": 600,
      "controlQueueBatchSize": 1024,
      "controlQueueBufferThreshold": 512
    }
  }
}

Answer 1

听起来您正在使用扇入扇出模式

下面对应示例代码的地方

• (F1) 从第三方服务获取更新列表（ID，通常在 20-30k 左右）
• (F2) 对于所有 ID，以一个 ID 作为输入调用另一个活动函数（并行）
• (F3) 汇总所有结果并从编排器返回

基于这个假设，我认为增加活动量对您的情况没有帮助，而只是创可贴。 分析您的遥测数据以查看我假设在 F2 中的 CPU 花费大部分时间的地方是我会做的。 此外，请查看Durable Functions (Azure Functions) 中的性能和规模，特别是性能目标部分，以确保您当前的配置不会无意中造成瓶颈。

如果您的摘要 (F3) 不依赖于已处理的 ID 批次，那么无状态是另一种执行方式，其中 F1 将 ID 输出到服务总线队列，然后 F2 被该服务总线触发。