c# - Azure持久框架功能应用程序非常慢

Question

我制作了一个使用azure函数的持久应用程序fan-out strategy通过向我们自己的内部 API 发送 http 请求来对数据库进行并行查询和更新。

我发现扇出策略比使用 TPL library 慢得多并在普通的 .net Core Web 应用程序上以这种方式进行并行处理。它不仅慢了，而且慢了大约 20 倍。 130 次更新需要 10 分钟，而我为速度比较而制作的 .net core 3.1 应用程序执行完全相同的操作，在 0.5 分钟内完成 130 次更新，而且计划要低得多。

我知道由于耐用的框架基础设施(与存储帐户等进行通信)而存在延迟，但我不明白这种速度差异是正常的。每个单独的更新都发生在 ActivityTrigger 函数中，编排器负责收集所有必要的更新并将它们放入 Task.WhenAll() 调用中，就像 Microsoft 文档中的示例一样。

我在这里做错了什么吗？这个业务场景可能不兼容这个技术吗？该代码似乎工作正常并且并行性有效，只是比 .net core 应用程序慢很多。另一件值得一提的是，当函数打开第二个实例时(由于它处于消耗计划中并自然打开第二个实例来处理重负载，或者它处于应用程序服务计划中并且我手动打开一个实例)，它甚至会发生尽管 CPU 负载在两个实例中以某种方式平衡，但速度较慢。我怀疑这可能是由于两个实例之间的 azure 队列通信造成的额外延迟，但我并不完全确定。

最后一个细节是，该应用程序还有一个 TimeTrigger，它每隔一分钟在数据库中执行一次简单的选择(甚至不会消耗 CPU 资源，但它可能会影响性能)。

我已经在高级计划、消费计划和应用程序服务计划中尝试过功能应用程序，无论计划有多大，它似乎都会在 10 分钟内达到 130 次更新。

Answer 1

一般来说，TPL 几乎总是比 Durable Functions 快得多，因为所有协调都是在内存中完成的(假设在一台机器上执行所有操作时不会完全耗尽系统资源)。所以这部分通常是预期的。以下是一些值得了解的要点:

• 事件函数的每个扇出都涉及一组队列事务:一条用于调用事件函数的消息和一条用于将结果传回编排器的消息。当涉及多个虚拟机时，您还必须担心队列轮询延迟。
• 默认情况下，单核虚拟机上事件函数的每个实例并发数限制为 10。如果您的事件函数不需要太多内存或 CPU，那么您将需要调高此值以增加每个实例的并发性。
• 如果您使用的是 Azure Functions 使用或高级计划，则需要 15-30 秒才能为您的应用添加新实例。如果您的工作负载可以通过在多台机器上运行来更快地完成，那么这一点很重要。消息在队列上等待的时间是驱动横向扩展的原因(1 秒被认为太长)。

您可以在 Durable Functions Performance and Scale documentation 中找到更多详细信息。 .

我要说的最后一件事是 Durable Functions 的关键附加值是在分布式环境中以可靠的方式编排工作。但是，如果您的工作负载不是长时间运行，不需要严格的持久性/弹性，不需要扩展到多个虚拟机，并且如果您有严格的延迟要求，那么 Durable Functions 可能不是正确的工具。如果您只需要单个虚拟机并且想要低延迟，那么使用内存中 TPL 的简单功能可能是更好的选择。