Проблемы параллельного использования базы данных Azure

Просто хотел запустить все это, чтобы увидеть, есть ли какие-то яркие идеи, поскольку я исчерпал все свои идеи после целого дня, ночи и утра в поисках. В ходе параллельного использования (тест селена) проблемы всегда были связаны вокруг базы данных. таймауты, сброшенные/закрытые соединения, сервер базы данных недоступен.

Проблема, по-видимому, ограничивается Azure, поскольку она еще не столкнулась с проблемой локально даже при выполнении одного и того же теста selenium на том же коде, указывающем на ту же базу данных (SQL Azure), что указывает на то, что это проблема с исходящей базы данных в SQL Azure. До сих пор мы пытались сделать следующее:

  • Обработка кратковременных ошибок Azure. У нас есть логика повтора для когда есть временная проблема с самой службой SQL Azure.
  • Измените протокол связи - Weve попробовал TCP и именованные каналы и мы сталкиваемся с той же проблемой с обоими.
  • Отрегулируйте интервал ожидания соединения с базой данных - Weve попытался увеличить это безрезультатно.
  • Добавление нескольких активных наборов результатов - Weve добавьте это в строка подключения безрезультатно.
  • Проверка состояния соединения для каждого запроса. Когда мы возвращаем DataContext мы проверяем его соединение и снова открываем там, где это необходимо.
  • Отключил пул соединений - Weve также попытался это без успех.
  • Измененная схема проектирования - Мы даже пошли на пути реализации шаблон проектирования Единицы работы, где соединения с базой данных были быть уволенным и уничтоженным после каждой единицы работы, но это вызвал проблемы в другом месте с ленивой загрузкой, передав объекты в методов, и это было бы слишком существенным переделкой на этом точка.

  • Изменить размер роли. Последнее, что я могу попытаться сделать, - это размер роли в случае каких-либо неявных ограничений подключения в Windows Azure - это в настоящее время развертывание, поэтому theres все еще половина шанса это может работать!

Инфраструктура сайта выглядит следующим образом:

  • Класс DataContext (расширяет DbContext), который является кодом First EF контекст.
  • Класс BusinessLayer содержит закрытый, нестатический DataContext. DataContext - это конструктор, вводимый в каждый класс Manager/Helper.
  • Класс BusinessLayerService содержит общедоступный поток, статический Экземпляр BusinessLayer.
  • Сайт MVC использует BusinessLayerService.Instance для доступа к менеджеру классы, которые запрашивают и обновляют DataContext, они переданы.

Любая помощь будет принята с благодарностью.

UPDATE: Мы увеличили размер виртуальной машины до Medium, и все, что было сделано, означало, что эта же проблема заняла больше времени.

Когда возникли проблемы, член команды отметил следующее исключение:

InvalidOperationException: для выполнения команды требуется открытое и доступное соединение. Состояние тока соединения сломано.

Это происходило при каждом удалении базы данных (не было специфично для определенной области кода).

Ответ 1

Я уже сталкивался с подобным вопросом. В моем случае это связано с тем, что объекты ObjectContexts Entity Framework не были утилизированы должным образом, прежде чем в конечном итоге слишком много контекстов развернулось и сайт опрокинулся. Мы идентифицировали с использованием Profiler Framework Entity Framework, что при возникновении ошибок были обнаружены много незакрытых объектов ObjectContext.

Нам не удалось перейти к шаблону проектирования подразделения (или аналогичному), так как потребовалось бы переписать бизнес-уровень, поэтому мы разрешили его, закрыв ObjectContext вручную после каждого запроса страницы. Мы применили подход к удалению контекста вручную в событии "Окончательный запрос" Global.asax, однако другие действительные подходы состояли в том, чтобы сохранить контекст в HttpContext или реализовать контейнер IoC (например, Castle Windsor) с "за запрос" "образ жизни.