将我们使用 Umbraco CMS (v6.2.6) 的网站之一从本地 Web 和数据库服务器迁移到 Azure 后，后台用户的性能受到了巨大影响。我尝试过扩展资源，但这不是问题所在，因为 DTU 利用率最高仅为 35%，即使出现爆发/峰值也是如此。SQL 服务器是 S0 标准服务层（10 个 DTU），它所在的资源组是 S3 标准服务层（4 核/7GB）——位于美国东部。
我复制了 Azure 应用服务和 SQL 数据库，并在 Azure 中将 New Relic 的一个实例附加到它，但发现的结果有点令人不安。
调用跟踪 #1 - 77% 的时间用于打开 SqlConnections
如果有任何区别的话，我使用本地 SQL 服务器实例在本地运行了相同的代码/测试，响应时间要快得多 - 几乎没有时间用于打开连接 -Localhost StackifyPrefix 跟踪。我没有编写数据层代码，因此此时调整它绝对是不可能的，尽管这看起来可能很尴尬……还有其他方法可以缓解这种情况吗？这似乎是一个荒谬的长时间，只是打开 SQL 连接很多次
答案1
这个问题的修复是在连接字符串中 - 在 2016 年 6 月，Azure SQL 数据库门户将其显示为 ADO.NET 的复制和粘贴连接字符串
Server=tcp:{your db resource group name},1433;Initial Catalog={your db instance};Persist Security Info=False;User ID={your_username};Password={your_password};Pooling=False;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;
在过去的 4 或 5 个月中的某个时候，他们Pooling=False从 ADO.NET 中的连接字符串示例中删除了它，但此时我刚刚将连接字符串从一个站点复制并粘贴到另一个站点，因为它已经有了数据库凭据/资源组名称，而我所要做的就是更改它指向的实际目录。
Close()当设置 Pooling=False 时，每次使用 .NET或在 .NET 中调用连接时Dispose()，连接实际上都会关闭，而不是返回到连接池以供以后使用。当需要新连接时，必须建立客户端和数据库服务器之间的 TCP 三次握手和通信，这可能会对具有大量查询的站点的性能产生重大影响。通过从连接字符串Pooling=False中删除，默认情况下，ADO.NET 会自动启用连接池功能。