当该网站已经被已经很少的+5用户使用并且我进行VIP交换时，我总是收到SQL错误，例如：
System.Data.Entity.Core.EntityCommandExecutionException: An error occurred while executing the command definition. See the inner exception for details. ---> System.Data.SqlClient.SqlException: A transport-level error has occurred when receiving results from the server. (provider: Session Provider, error: 19 - Physical connection is not usable)
我正在使用SqlAzureExecutionStrategy.此外，VIP交换期间的其他请求似乎需要大约~30秒，使站点真正没有响应，尽管暂存环境已经完全预热。
- 有什么办法可以防止这种情况吗？
- 为什么我没有读太多关于这种行为的信息？其他人只是不关心一些损坏的请求和缓慢的 30 年代时间范围，还是我在 Sql/EF 设置中缺少一些重要的东西？
您实际上是在站点处于生产状态时交换实时代码。 你肯定会得到各种各样的错误。 总会有一瞬间服务不存在。 部署新的 SQL 架构时也是如此。
你需要做的是意识到这将会发生，并围绕它进行工程设计。 强大的开发运营团队在这里大放异彩。 我个人所做的是在不同的地理位置进行分阶段部署。 在升级东海岸时，我将让流量管理器将所有流量指向西海岸 Web 服务器。 然后，我在更新西海岸时将所有流量指向东海岸。 然后，我将流量管理恢复正常。
若要从东向西分配流量，通常使用流量管理器设置单个终结点，该终结点在后台指向正确的终结点，充当代理。 只需删除要升级的端点，这将强制重定向到实时站点。 升级完成后，重新添加终结点。
还应确保代码能够很好地处理错误。 例如，如果需要与外部系统同步，并且在升级期间将单个记录输入到系统中，而不是外部记录，是否可以使用您的数据重建外部系统的状态，反之亦然。
我终于迈出了切换到 Azure Web 应用而不是云服务的步骤，所有这些问题都已解决，甚至更多。
花了几天时间，但切换绝对值得。
为意外离开暂存服务器付费也是过去的问题。