我们有一套 5 个在 Windows Azure 和 SQL Azure 上运行的在线拍卖系统。每个系统由一个 Web Worker 和一个或多个 Web 角色组成。每个系统都使用 ASP.NET MVC 3 和 Entity Framework、Repository Pattern 和 StructureMap。
worker 角色负责内务管理并运行两组进程。一组每十秒运行一次，另一组每秒运行一次。每个进程都可能运行数据库查询或存储过程。这些是用 Quartz.net 安排的
Web 角色服务于公共界面和后台。在其他基本的 crud 功能中，这两个都提供屏幕，当打开时，将重复调用控制器方法，这将导致执行存储过程只读查询。重复频率约为每位客户 2-3 秒。一个典型的用例是打开 5 个后台办公室窗口，并打开 25 个最终用户窗口——所有这些窗口都在重复访问系统。
很长一段时间以来，我们一直在遇到间歇性 SQL 超时错误。最常见的三个是：
System.Data.SqlClient.SqlException：从服务器接收结果时发生传输级错误。（提供者：TCP 提供者，错误：0 - 现有连接被远程主机强行关闭。）
System.Data.SqlClient.SqlException：从服务器接收结果时发生传输级错误。（提供者：TCP 提供者，错误：0 - 信号量超时期限已过。）
System.Data.SqlClient.SqlException：超时已过期。在操作完成之前超时时间已过或服务器没有响应。
唯一可预测的情况是在拍卖期间，特定控制器 -> sproc 在事件期间开始超时（可能是由于负载）。在所有其他时间，即使在用户不活动期间，错误似乎都是完全随机的，并且出现单次、两次和三次等错误。例如，系统将运行 18 个小时而没有错误，然后可能会出现 5 到 10 个来自不同内务管理方法的错误，或者可能是用户登录并查看了他们的帐户。
其他信息：
我尝试使用本地 SSMS 和 Azure 基于 Web 的查询工具在 SQL Azure 上运行受影响的查询/存储过程——所有这些似乎都执行得很快，最多 1 秒。尽管我绝不是 SQL 查询性能专家，也不是任何其他类型的专家，但查询计划并没有显示任何太可疑的东西 J
我们已经在 Azure SQL 瞬态故障处理块中包装了所有受影响的区域——但正如这里所讨论的那样http://social.msdn.microsoft.com/Forums/en-US/ssdsgetstarted/thread/7a50985d-92c2-472f-9464-a6591efec4b3，他们没有捕捉到超时，根据“Valery M”的说法，这是有充分理由的。
我们没有在数据库中存储任何会话信息，尽管 asp.net 成员信息存储在数据库中。
我们使用 1 个“SQL Azure 服务器实例”托管所有 5 个数据库，两个用于暂存，三个用于生产。所有 5 个系统通常同时处于活动状态，尽管在任何给定时间不太可能有超过一个系统处于活载使用状态。所有 Web 角色、辅助角色和 SQL Azure 服务器都位于同一个 Azure 地理区域。
关于我们应该在哪里寻找的任何想法？为每个系统提供自己的 SQL Azure 服务器会有所帮助吗？......我们自己的解决方案失败 - 是否有可能让微软打开支持票并查看我们的应用程序发生了什么 - 一个人如何解决这个问题？
提前致谢。
宜兰