我已经制作了一个使用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核心应用程序慢很多。还要提到的另一件事是，该函数打开第二个实例的瞬间（由于它处于消耗计划中，并且自然地打开了第二个实例以处理繁重的工作，或者它处于appservice计划中，而我手动打开了一个实例），它甚至变得尽管CPU负载在两个实例中以某种方式平衡，但速度较慢。我怀疑这可能是由于两个实例之间的天蓝色队列通信而导致的额外延迟，但我不确定。
最后一个细节是，该应用程序还具有一个TimeTrigger，它每隔一分钟在数据库中进行一次简单的选择（即使是远程CPU也不耗费时间，但可能会影响性能）。
我已经在高级计划，使用计划和appservice计划中试用了功能应用程序，无论计划有多大，它似乎在10分钟内最多可以更新130次。
答案 0 :(得分：0)
总的来说，TPL几乎总是比耐用功能快得多，因为所有协调都是在内存中完成的（假设不会完全耗尽系统资源在一台机器上的所有工作）。因此，这部分通常是可以预期的。这里有一些要点：
您可以在Durable Functions Performance and Scale documentation中找到更多详细信息。
我要说的最后一件事是，持久功能的关键附加值是在分布式环境中以可靠的方式协调工作。但是，如果您的工作负载不是长期运行的，不需要严格的持久性/弹性，也不需要横向扩展到多个VM，并且如果您有严格的延迟要求，那么“持久功能”可能不是正确的工具。如果您只需要一个VM并希望低延迟，那么使用内存中TPL的简单功能可能是更好的选择。