我們有一套在Windows Azure上運行的5個在線拍賣系統& SQL Azure。每個系統由一個Web工作人員和一個或多個Web角色組成。每個系統都使用ASP.NET MVC 3和實體框架，存儲庫模式和結構圖。SQL Azure：更多間歇性超時
工作者角色負責管家並運行兩組進程。一組每十秒運行一次，另一組每秒運行一次。每個進程都可能運行數據庫查詢或存儲過程。這些預定與Quartz.net
網絡角色服務於公共界面和後臺。除了其他基本的crud功能之外，它們都提供了這樣的屏幕，當打開時，它們將重複調用將導致執行存儲過程只讀查詢的控制器方法。每個客戶端的重複頻率約爲2-3秒。一個典型的用例是打開5個後臺窗口，打開25個最終用戶窗口 - 所有操作都反覆進行。
很長一段時間我們一直在經歷間歇性的SQL超時錯誤。最常見的三種是：
System.Data.SqlClient.SqlException: A transport-level error has occurred when receiving results from the server. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)
System.Data.SqlClient.SqlException: A transport-level error has occurred when receiving results from the server. (provider: TCP Provider, error: 0 - The semaphore timeout period has expired.)
System.Data.SqlClient.SqlException: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
唯一可預見的情形是，特定的控制器的拍賣中 - >存儲過程開始時（大概是由於負載）時超時。在所有其他時間，即使在用戶不活動期間，錯誤似乎完全是隨機的，並會出現單打，雙打和三等。例如，系統將持續18小時而沒有錯誤，然後可能是來自不同內務管理方法的5 - 10個錯誤，或者用戶可能登錄並查看了他們的帳戶。
其他信息：
我試圖運行在SQL Azure的同時使用本地SSMS和Azure的基於Web的查詢工具受影響的查詢/存儲過程 - 似乎都快速執行，最長1秒。查詢計劃沒有顯示任何太可疑的信息，儘管我絕不是SQL查詢性能專家或任何其他類型的專家對於此事J
我們已將Azure SQL瞬態故障處理塊中的所有受影響區域在這裏討論http://social.msdn.microsoft.com/Forums/en-US/ssdsgetstarted/thread/7a50985d-92c2-472f-9464-a6591efec4b3，他們不會超時，並根據「瓦列裏米」這是很有道理的。
儘管asp.net會員信息存儲在數據庫中，但我們並未在數據庫中存儲任何會話信息。
我們使用1個「SQL Azure服務器實例」，它承載所有5個數據庫，兩個用於分段，三個用於生產。所有5個系統通常同時處於活動狀態，但在任何給定的時間內，不可能有多於一個處於活動負載狀態。 所有Web角色，工作角色和SQL Azure服務器都駐留在同一個Azure地理區域中。
有關我們應該在哪裏尋找的想法？它有助於爲每個系統提供自己的SQL Azure服務器嗎？ ......我們自己沒有解決方案 - 是否有可能讓微軟公開支持票，並仔細研究我們的應用程序正在發生什麼 - 人們如何去解決這個問題？
在此先感謝。
宜蘭
宜蘭，現在我遇到了同樣的類型了應用的錯誤。你最終做了什麼？順便說一下，在那個短暫的錯誤帖子中，Valery M說如果執行計劃和數據庫索引看起來很好，那麼至少在一些無法解決的超時中使用該模式可能是可以的。 –