Posiadamy zestaw 5 systemów aukcji internetowych działających w systemie Windows Azure i SQL Azure. Każdy system składa się z jednego pracownika WWW i jednej lub kilku ról internetowych. Każdy system korzysta z ASP.NET MVC 3 i Entity Framework, Repository Pattern i StructureMap.

Rola pracownika jest odpowiedzialna za porządkowanie i uruchamia dwie grupy procesów. Jedna grupa jest uruchamiana co dziesięć sekund, druga co sekundę. Każdy proces prawdopodobnie uruchomi zapytanie do bazy danych lub procedurę składowaną. Są one zaplanowane w Quartz.net

Rola internetowa służy interfejsowi publicznemu i zapleczu. Wśród innych podstawowych funkcji crud, obie z nich udostępniają ekrany, które po otwarciu będą wielokrotnie wywoływać metody kontrolera, co spowoduje wykonanie zapytań składowanych tylko do procedury. Częstotliwość powtarzania wynosi około 2-3 sekund na klienta. Typowy przypadek użycia to 5 otwartych okien zaplecza i 25 otwartych okien użytkownika końcowego - wszystkie trafiają do systemu wielokrotnie.

Przez długi czas występowały sporadyczne błędy limitu czasu SQL. Trzy z najbardziej powszechnych to:

System.Data.SqlClient.SqlException: Wystąpił błąd poziomu transportu podczas odbierania wyników z serwera. (dostawca: dostawca TCP, błąd: 0 - istniejące połączenie zostało przymusowo zamknięte przez zdalnego hosta).

System.Data.SqlClient.SqlException: Wystąpił błąd poziomu transportu podczas odbierania wyników z serwera. (provider: TCP Provider, error: 0 - Upłynął limit czasu semafora.)

System.Data.SqlClient.SqlException: Upłynął limit czasu. Limit czasu, który upłynął przed zakończeniem operacji lub serwer nie odpowiada.

Jedynym przewidywalnym scenariuszem jest aukcja, w której określony kontroler -> sproc rozpoczyna limit czasu podczas zdarzenia (prawdopodobnie z powodu obciążenia). Innym razem błędy wydają się być całkowicie losowe i pojawiają się w pojedynkach, dwóch i trzech itd., Nawet w okresach braku aktywności użytkownika. Na przykład system przejdzie 18 godzin bez błędu, a następnie może być 5-10 błędów z różnych metod sprzątania, a może użytkownik zaloguje się i obejrzy swoje konto.

Inne informacje:

Próbowałem uruchamiać zapytania / sprocesy na SQL Azure przy użyciu lokalnego narzędzia do zapytań SSMS i Azure - wszystko wydaje się wykonywać szybko, maks. 1 sekunda. Zapytania nie pokazują niczego zbyt podejrzanego, chociaż w żadnym wypadku nie jestem ekspertem od wykonywania zapytań SQL, ani żadnym innym ekspertem w tym zakresie J

Zawinęliśmy wszystkie obszary, których dotyczy problem, w bloki Azure SQL Transient Fault Handling - ale jak omówiono tutajhttp://social.msdn.microsoft.com/Forums/en-US/ssdsgetstarted/thread/7a50985d-92c2-472f-9464-a6591efec4b3, nie łapią limitu czasu, a według „Valery M” jest to dobry powód.

Nie przechowujemy żadnych informacji o sesji w bazie danych, chociaż informacje o członkostwie asp.net są przechowywane w bazie danych.

Korzystamy z 1 „instancji serwera SQL Azure”, która obsługuje wszystkie 5 baz danych, dwie do przemieszczania i trzy do produkcji. Wszystkie 5 systemów jest generalnie aktywnych w tym samym czasie, chociaż jest mało prawdopodobne, aby więcej niż jeden był w stanie wykorzystania obciążenia na żywo w danym momencie. Wszystkie role sieciowe, role robocze i serwer SQL Azure znajdują się w tym samym regionie geograficznym Azure.

Jakieś myśli o tym, gdzie powinniśmy szukać? Czy pomogłoby to nadać każdemu systemowi własny serwer SQL Azure? ... Niepowodzenie rozwiązania samodzielnie - czy można skłonić firmę Microsoft do otwarcia biletu pomocy technicznej i spojrzeć pod maską na to, co dzieje się z naszą aplikacją - jak sobie z tym poradzić?

Z góry dziękuję.

Ilan