Azure SQL GeoReplication - запросы к вторичной БД медленнее - PullRequest
Новая
       29

Azure SQL GeoReplication - запросы к вторичной БД медленнее

0 голосов
/ 05 июня 2018

Я установил две базы данных SQL в Azure с гео-репликацией.Основной находится в Бразилии, а второй в Западной Европе.Точно так же у меня есть два веб-приложения, работающие на одном веб-API.Бразильское веб-приложение, которое читает и пишет в бразильской БД, и европейское веб-приложение, которое читает в европейской БД и пишет в бразильской БД.

Когда я проверяю время ответа на запросы только для чтения с почтальоном из ЕвропыЯ впервые заметил, что при первом «холодном» звонке европейское веб-приложение в два раза быстрее бразильского.Однако время немедленного ответа на следующие вызовы в веб-приложении Bazilian составляет 10% от первоначального «холодного» вызова, тогда как время ответа в европейском веб-приложении остается неизменным.Я также заметил, что после нескольких минут бездействия результаты возвращаются к «холодному» случаю.

Итак:

  1. Почему в Бразилии время ответа на запрос уменьшается?
  2. каков бы ни был ответ на вопрос 1, почему это не происходит в Европе?
  3. почему оптимизация времени отклика, происходящая в 1, не длится после нескольких минут бездействия?

Обратите внимание, что веб-приложения и БД создаются как копирование / вставка (кроме гео-репликации) друг в друга в json-файле Azure ARM.Оба веб-приложения alwaysOn.

Спасибо.

ОБНОВЛЕНИЕ

На самом деле в том, что я вижу как конечный пользователь, есть несколько частей в действии.Веб-приложения и базы данных.Я написал этот вопрос, думая, что проблема связана с базой данных и гео-репликацией, однако, после попытки сценария @ Alberto (см. Ниже), я не смог «увидеть какие-либо различия в wait_times при запросе Бразилии или Европы, поэтомупроблема может быть в веб-приложениях.Я не знаю, как дальше анализировать / тестировать это.

ОБНОВЛЕНИЕ 2

Это может быть (или не) связано с хранилищем запросов.Я задал новый более конкретный вопрос на эту тему.

ОБНОВЛЕНИЕ 3

Запросы к вторичной базе данных не медленнее.Мой вопрос был поднят на ложные выводы.Я не буду удалять его, поскольку другим потребовалось время, чтобы ответить на него, и я благодарю их.

Я сравнивал время отклика запросов через оставшиеся вызовы с веб-API, выполняющим запросы EF на БД SQL Server.Поскольку остальные вызовы веб-API, расположенного в регионе, запрашивающего реплику базы данных, медленнее, чем остальные вызовы того же веб-API, развернутого в другом регионе и предназначенного для основной базы данных, я пришел к выводу, что проблема была на стороне базы данных.Тем не менее, когда я запускаю запросы в SSMS напрямую, минуя веб-API, я почти не вижу различий во времени отклика между первичной базой данных и базой данных реплики.

У меня все еще есть проблема, но не та, которая была поднята в этом вопросе.

1 Ответ

0 голосов
/ 05 июня 2018

В базе данных SQL Azure Использование памяти вашей базы данных может динамически сокращаться после нескольких минут бездействия, и в этом случае Azure SQL отличается от локального SQL Server.Если вы выполняете запрос два или три раза, он снова начинает выполняться быстрее.

Если вы изучите план выполнения запроса и его статистику ожидания, вы можете найти ожидание с именем MEMORY_ALLOCATION_EXT для тех запросов, которые выполняются после выделения памяти.был сокращен службой базы данных Azure SQL.Базы данных с большой активностью и выполнением запросов могут не видеть своего сокращения памяти.Для получения подробной информации о моей части, пожалуйста, прочитайте этот поток StackOverflow.

Примите также во внимание, что обеим базам данных должен быть присвоен одинаковый уровень обслуживания.

Используйте приведенный ниже скрипт для определениязапрос ждет и посмотрим, в чем разница с точки зрения ожиданий между двумя регионами. 

DROP TABLE IF EXISTS #before;

 SELECT [wait_type], [waiting_tasks_count], [wait_time_ms], [max_wait_time_ms],
        [signal_wait_time_ms]
 INTO #before
 FROM sys.[dm_db_wait_stats];

 -- Execute test query here

 SELECT *
 FROM [dbo].[YourTestQuery]

  -- Finish test query

DROP TABLE IF EXISTS #after;

 SELECT [wait_type], [waiting_tasks_count], [wait_time_ms], [max_wait_time_ms],
        [signal_wait_time_ms]
 INTO #after
 FROM sys.[dm_db_wait_stats];

 -- Show accumulated wait time

 SELECT [a].[wait_type], ([a].[wait_time_ms] - [b].[wait_time_ms]) AS [wait_time]
 FROM [#after] AS [a]
 INNER JOIN [#before] AS [b] ON
  [a].[wait_type] = [b].[wait_type]
 ORDER BY ([a].[wait_time_ms] - [b].[wait_time_ms]) DESC;
...