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

Question

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

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

1. Обработка временных ошибок Azure. У нас есть логика повторных попыток, когда возникает временная проблема с самой службой SQL Azure.
2. Изменить протокол связи - мы попробовали и TCP, и именованные каналы, и мы сталкиваемся с одной и той же проблемой.
3. Настройте интервал ожидания соединения с базой данных - мы пытались увеличить это безрезультатно.
4. Добавление нескольких активных наборов результатов - мы добавили это в строку подключения безрезультатно.
5. Проверка состояния соединения для каждого запроса. Когда мы возвращаем DataContext, мы проверяем его соединение и открываем его снова, когда это необходимо.
6. Отключил пул соединений - мы также пытались это сделать безуспешно.

7. Измененный шаблон проектирования - мы даже пошли на этапы внедрения шаблона проектирования Unit of Work, где соединения с базой данных запускались и удалялись после каждой единицы работы, но это вызывало проблемы в других местах с отложенной загрузкой, передачей объектов в методы и было бы слишком существенной переделкой на этом этапе.

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

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

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

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

ОБНОВЛЕНИЕ: Мы увеличили размер виртуальной машины до среднего, и все, что он сделал, означало, что та же самая проблема заняла больше времени.

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

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

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

Answer 1

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

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