Производительность базы данных пула Azure Elastic

Question

Мы сталкиваемся с подобной проблемой, о которой упоминалось в Azure, которая слишком легко преодолевает ограничения ЦП базы данных. Мы также используем пул Azure Elastic и создаем новую базу данных для каждого клиента. Мы используем EF6-code-first для обработки SQL.

Используя веб-интерфейс, пользователь может создать клиента. Они делают это несколько раз в неделю, а иногда (не всегда, но раз в неделю) база данных создается только частично, и мы получаем Microsoft.Azure.SqlDatabase.ElasticScale.ShardManagement ошибки. Когда мы удаляем этот клиент / DB и создаем снова, он работает нормально. Конечно это очень раздражает. Сейчас мы работаем над обнаружением этой ошибки, удалим базу данных и возобновим создание в коде. У кого-нибудь есть подобный опыт и, надеюсь, лучшее решение?

Также создание базы данных занимает много времени: 3-5 минут. У нас только 18 таблиц на базу данных. Можем ли мы ускорить это?

Следующим шагом в рабочем процессе является анализ XML-файлов, загруженных пользователем. Мы используем EF6, чтобы заполнить нашу модель и сохранить ее в базе данных. Это действительно медленно. XML-файл содержит данные о сотрудниках, которые нам нужно заполнить в несколько таблиц (около 15 таблиц). Например, у нас есть XML-файл объемом 9,7 МБ, содержащий 4416 сотрудников, а шаг.save() занимает около 12 минут. Принимая во внимание, что клиент имеет около 25 XML-файлов каждый год, а пользователь загружает 5 лет сразу, эта экономия занимает слишком много времени.

Мы уже посмотрели на код и в рамках EF6 мы не думаем, что сможем оптимизировать его больше. Сейчас мы рассматриваем конфигурацию нашей подписки Azure, но документация пугает, и мы не можем понять, что нужно изменить, чтобы повысить производительность.

Любое руководство высоко ценится.

Answer 1

Я пересылаю этот вопрос на форуме Microsoft Azure > База данных SQL Azure: https://social.msdn.microsoft.com/Forums/en-US/b7c7ad0a-0be4-4b15-8ae6-494181ec60b1/how-to-increase-max-number-of-databases-allowed-without-increasing-pricetier?forum=ssdsgetstarted И ответ:

Вы не можете частично (только определенные ресурсы) масштабировать до другого уровня. Вы не можете масштабировать только максимальное количество баз данных.

Это не тот ответ, на который я надеялся.

Answer 2

У меня есть облачное приложение, которое очень похоже создает новые экземпляры клиентов с новым осколком базы данных. Я обнаружил, что код, который создает эти базы данных Azure, должен быть ОЧЕНЬ отказоустойчивым. Вот что я делаю:

1. При создании базы данных используйте очень большой тайм-аут - не менее 5 минут. Возвращение занимает много времени.

2. Подождите еще дольше, потому что, несмотря на то, что скрипт был запущен и выполнение вернулось к вашему приложению, база данных все еще не доступна для использования. У меня есть простой запрос, который я запускаю к ​​базе данных каждые 10 секунд. Сначала запрос выдает исключение при запуске; Я ловлю исключение, чтобы предотвратить всплеск ошибки. Через некоторое время запрос будет успешно выполнен, и вы знаете, что база данных готова к приему запросов. Я прекращаю после 50 попыток предотвратить неопределенный цикл, если Azure никогда не создает таблицу успешно.

Теперь, как правило, это плохая практика - использовать try / catch для обычного выполнения программы и повторять поиск ресурса снова и снова, однако, как я обнаружил, это единственный подход, который работает 100% времени для этой проблемы.