我们有一个 v1 Azure Function App。它必须是 v1，因为我们的客户坚持使用 .NET Framework，因为他们的组织熟悉 Framework，并且尚未迁移到 .NET Core。
我们的架构师规定 MARS（多活动记录集）应在 connectionString 上设置为 false，因为 Azure 函数应用程序是多线程的，并且 MARS 不是线程安全的，根据：https ://docs.microsoft.com/en-我们/sql/connect/ado-net/sql/enable-multiple-active-result-sets?view=sql-server-ver15 -。
最初它是用 DbDataReader 实现的，我们也用 DbDataAdapter 实现了它。有问题的 SP 返回两个结果集，并执行 sub 1 秒。Function App 和 Azure SQL Server 实例位于同一个 Azure 区域。
我们已经进行了更深入的配置文件跟踪，请求需要 3-7 秒（有时更长时间）来填充 DataSet（在您说返回阅读器之前，会发生相同的性能）。这是针对零行的结果集。同样，SP 在不到 1 秒的时间内执行。来自世界其他地方的网络性能（英国的 SQL，ZA 的开发），它仍然在不到 1 秒的时间内从欧洲遍历到非洲（我们正在执行的地方）。
在更深入的检查中，填充需要很长时间：
我们无能为力来优化代码。
问题是：
- 是否可以安全地在与 Azure 函数应用一起使用的连接字符串上启用 MARS，如果不能，为什么不呢？
- 我们如何使 DataFills 在 .NET Framework Azure Function 应用程序中具有更高的性能？
有问题的函数应用程序有其他方法等。如果我们不能使用 MARS 或进行其他性能调整/调整，那么我们目前的想法是我们必须将此特定方法调用拆分为某种 v2 .NET Core 函数应用程序或其他一些用于高性能数据填充的方法。
客户非常注重成本（哪个客户不是？）并且他们对 Azure 中的额外资源非常谨慎 - 想想一个深层的官僚机构 - 所以调整或使用 MARS（或其他 ConnString 调整）是首选。