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

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

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

我知道由于持久的framwork基础架构（与存储帐户等通信）存在延迟，但我不认为这种速度差异是正常的。每个单独的更新都发生在ActivityTrigger函数中，orchestrator收集所有必要的更新并将其放入Task.WhenAll（）调用中，就像Microsoft docs中的示例一样

我做错什么了吗？此业务场景是否可能与此技术不兼容？代码似乎运行良好，并行性也运行良好，只是比.net核心应用程序慢了很多。另一件需要提及的事情是，函数打开第二个实例的那一刻（由于它在consuption plan中并且自然地打开第二个实例来处理重负载，或者它在appservice plan中并且我手动打开了一个实例），它会变得更慢，尽管cpu负载在这两个实例中以某种方式平衡。我怀疑这可能是由于两个实例之间的azure队列通信造成的额外延迟，但我不完全确定

最后一个细节是，该应用程序还有一个TimeTrigger，它每一分钟在数据库中执行一次简单的选择（即使是远程cpu密集型操作，也没有什么，但它可能会影响性能）

---

我已经在高级计划、消费计划和应用服务计划中尝试过功能应用程序，无论计划有多大，它似乎在10分钟内更新了130次。一般来说，TPL几乎总是比持久功能快得多，因为所有的协调都是在内存中完成的（假设在一台机器上完成所有工作时不会完全耗尽系统资源）。因此，这一部分通常是意料之中的。这里有几点值得了解：

• 活动函数的每个扇出都涉及一组队列事务：一条消息用于调用活动函数，另一条消息用于将结果返回给编排器。当涉及多个VM时，您还必须担心队列轮询延迟
• 默认情况下，单个核心VM上活动函数的每实例并发性限制为10。如果活动函数不需要太多内存或CPU，则需要增大此值以增加每实例并发性
• 如果您正在使用Azure功能消费或高级计划，则需要15-30秒才能为您的应用添加新实例。这主要是因为在多台计算机上运行可以加快您的工作负载。消息在队列上等待的时间会导致扩展（1秒被认为太长）

您可以在中找到有关此的更多详细信息

---

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

您正在更新哪种类型的数据库？（SQL Server、Cosmos DB，…）@PrebenHuybrechts这是一个简单的MSSQL数据库，非常轻量级，到目前为止几乎没有任何数据。该项目正在开发中。您使用的是SQL数据库吗？（SQL Server PaaS）？您为它分配了多少DTU？@ThiagoCustodio不，我没有。我正在使用MSSQL和实体框架。数据库操作实际上没有任何区别，因为它们是最小的（每分钟一次）。我在数据库上使用尽可能低的DTU。虽然需要时间的作业没有使用数据库操作，但它只是进行大量API调用。只有时间触发器每分钟执行一个sql数据库操作。你错了。首先，你不能将本地性能与云计算性能进行比较。只是为了访问数据库，它会经过多次跳数增加了执行函数的预期时间。其次，DTU实际上会提高此过程的性能。我100%确信，如果您增加，您将获得更好的结果。此外，尝试编写update语句，而不是EF生成的语句。我尝试从默认的10增加更多并发性，但没有发现任何改进，该应用程序打开了第二个实例，从那时起，它甚至比拥有一个实例还要慢。你的观点似乎证实了我的怀疑。我选择持久框架的原因是因为此作业将长期运行。我希望最大运行时间限制为2小时。但我需要在这些小时内获得最大性能。在我所支持的核心web api中为了在一个小时内更换功能技术，我用数据库更新完成了9000个或更多。在持久性方面，这需要10个多小时（我在这一点上停止了）。