【发布时间】：2012-09-17 01:06:06
【问题描述】：
只是想由大家运行一下，看看是否有任何好的想法，因为经过一整天、一夜和一早的搜索，我已经用尽了所有的想法。在并发使用（硒测试）时，我们遇到的问题总是围绕数据库连接，例如超时、断开/关闭的连接、无法访问数据库服务器。
这个问题似乎仅限于 Azure，因为即使在指向同一个数据库 (SQL Azure) 的相同代码上运行相同的 selenium 测试时，我们还没有在本地遇到这个问题，所以它会指出它是一些SQL Azure 中的出站数据库连接问题。到目前为止，我们已经尝试了以下方法：
- Azure 瞬态故障处理 – 我们为 当 SQL Azure 服务本身出现临时问题时。
- 更改通信协议 - 我们尝试了 TCP 和命名管道 我们遇到了同样的问题。
- 调整数据库连接超时间隔 - 我们尝试增加 这无济于事。
- 添加多个活动结果集 – 我们已将其添加到 连接字符串无济于事。
- 对每个查询进行连接状态检查 – 当我们返回 我们检查 DataContext 的连接并在必要时重新打开。
- 关闭连接池 - 我们也尝试过 成功。
改变了设计模式——我们甚至竭尽全力实现 工作单元设计模式，其中数据库连接位于 在每个工作单元之后被解雇和处理，但这 在其他地方导致延迟加载问题，将对象传递到 方法，而且在这方面的返工太重了 点。
更改角色大小 - 我能想到的最后一件事就是提高 Windows 中存在任何隐式连接限制时的角色大小 Azure——目前正在部署，所以仍有一半的机会 可能有用！
网站基础架构如下：
- DataContext 类（扩展 DbContext），它是 Code First EF 上下文。
- BusinessLayer 类包含一个私有的非静态 DataContext。 DataContext 是注入到每个 Manager/Helper 类中的构造函数。
- BusinessLayerService 类包含一个公共的、线程静态的 BusinessLayer 实例。
- MVC 站点使用 BusinessLayerService.Instance 访问管理器 查询和更新已传递的 DataContext 的类。
任何帮助将不胜感激。
更新：我们将 VM 大小提高到中等，这意味着同样的问题需要更长的时间才会发生。
当问题开始出现时，一名团队成员注意到发生了以下异常：
InvalidOperationException：命令的执行需要一个打开且可用的连接。连接的当前状态已断开。
每当数据库被击中时就会发生这种情况（不特定于某个代码区域）。
【问题讨论】：
-
您是否尝试过使用经典的 ADO.Net 方法而不是 EF？有人告诉我，在使用 SQL Azure 时，人们使用 EF 的问题比使用 ADO.Net 的问题更多。
-
@GauravMantri 问题是，这个和我们已经在野外已经拥有的各种其他项目都使用 EF，因此切换到 ADO.NET 将是一个既耗时又昂贵的过程 :)
-
您使用的实例大小是多少？请记住，网络带宽也受到实例大小的限制，因此小型实例只有 ~100Mb。
-
我要做的一件事是增强瞬态故障处理框架 (TFHF) 的使用。默认情况下，它只使用/处理数据库级故障。但是您还需要考虑其他故障，例如负载均衡器错误。例如，您可能会收到 SocketIO 错误，这取决于错误本身可能是一种限制形式或需要重试的简单网络错误。所以我想说确保您查看实际的异常并确定是否应将它们添加到 TFHF。
-
@mattytommo This 可能会有所帮助
标签： azure concurrency azure-sql-database database-concurrency