У нас есть набор из 5 систем онлайн-аукционов, работающих на Windows Azure & amp; SQL Azure. Каждая система состоит из одного веб-работника и одной или нескольких веб-ролей. Каждая система использует ASP.NET MVC 3 и Entity Framework, Repository Pattern и StructureMap.

Рабочая роль отвечает за ведение домашнего хозяйства и управляет двумя группами процессов. Одна группа запускается каждые десять секунд, другая - каждую секунду. Каждый процесс, скорее всего, будет выполнять запрос к базе данных или хранимую процедуру. Это запланировано с Quartz.net

Веб-роль служит общедоступному интерфейсу и бэк-офису. Среди других базовых функциональных возможностей, оба они предоставляют экраны, которые при открытии будут неоднократно вызывать методы контроллера, что приведет к выполнению запросов хранимых процедур только для чтения. Частота повторения составляет около 2-3 секунд на одного клиента. Типичный вариант использования - это 5 открытых окон бэк-офиса и 25 окон конечного пользователя & # x2013; все попало в систему неоднократно.

В течение долгого времени мы испытывали периодические ошибки времени ожидания 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.

Единственный предсказуемый сценарий - во время аукциона, где конкретный контроллер - & gt; sproc начинает тайм-аут во время события (предположительно, из-за нагрузки). В остальное время ошибки кажутся абсолютно случайными и появляются в виде одиночных, двух и трех и т. Д. Даже в периоды бездействия пользователя. Например, система будет работать без ошибок 18 часов, а затем может быть 5 & # x2013; 10 ошибок от разных методов ведения домашнего хозяйства, или, возможно, пользователь вошел в систему и просмотрел свою учетную запись.

Другая информация:

Я пытался запустить затронутые запросы / спроки в SQL Azure, используя как локальную SSMS, так и веб-инструмент запросов Azure & # x2013; кажется, все выполняется быстро, 1 секунда макс. Планы запросов не показывают ничего слишком подозрительного, хотя я ни в коем случае не являюсь экспертом по производительности SQL-запросов или любым другим экспертом в этом отношении.

Мы обернули все уязвимые области в блоки обработки временных ошибок Azure SQL & # x2013; но как обсуждается здесьhttp://social.msdn.microsoft.com/Forums/en-US/ssdsgetstarted/thread/7a50985d-92c2-472f-9464-a6591efec4b3они не улавливают таймауты, и, согласно & # x201C; Валерий М & # x201D; это не зря.

Мы не храним информацию о сеансе в базе данных, хотя информация о членстве asp.net хранится в базе данных.

Мы используем 1 & # x201C; экземпляр сервера SQL Azure & # x201D; где размещены все 5 баз данных, две для подготовки и три для производства. Все 5 систем, как правило, активны одновременно, хотя маловероятно, что в какой-либо момент времени более одной будет использоваться нагрузка под напряжением. Все веб-роли, рабочие роли и сервер SQL Azure находятся в одном географическом регионе Azure.

Есть мысли о том, где мы должны искать? Поможет ли это предоставить каждой системе собственный сервер SQL Azure? ... Если мы сами не найдем решение - можно ли заставить Microsoft открыть заявку в службу поддержки и посмотреть, что происходит с нашим приложением & # x2013; как можно это сделать?

Заранее спасибо.

Илан