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

Question

Мы столкнулись с аналогичной проблемой, упомянутой в Azure hits database cpu limits too easily. Мы также используем пул Azure Elastic и создаем новую базу данных для каждого клиента. Мы используем сначала EF6-код для обработки SQL-данных.

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

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

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

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

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

Answer 1

Я пересекаю-сообщению этот вопрос на Microsoft Azure> Azure SQL Database форум: 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 никогда не будет успешно создавать таблицу.

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