Производительность запросов Microsoft Sync Framework

Мы разрабатываем продукт, который использует Microsoft Sync Framework для синхронизации данных в клиентском приложении и на сервере. Мы заметили, что при синхронизации около 16 таблиц и ~ 2200 записей это займет около 4 минут, что неприемлемо.

Используя SQL Server Profiler, мы обнаружили, что он использует sp_executesql для выполнения запросов. при запуске без sp_executesql конкретный запрос выполняется за ‹1 с, но с ним он занимает более 10 с.

Возникает вопрос: что мы делаем не так и можем ли мы что-то сделать, чтобы ускорить это.


person John Boker    schedule 12.11.2008    source источник


Ответы (2)


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

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

ознакомьтесь с этой ссылкой, которая охватывает основы:

Основные сведения о плане выполнения SQL

Попробуйте прокрутить статью до конца, где есть снимки экрана реального графического интерфейса в SQL Management Studio. В статье есть несколько скучных частей, но вы, по крайней мере, можете увидеть графический план выполнения и его преимущества.

person D3vtr0n    schedule 04.12.2008

Улучшения производительности перечислены на MSDN в разделе «Что нового» для Sync Framework 2.0.

Повышение производительности

Новые поставщики баз данных в этом выпуске были тщательно протестированы в сценариях масштабного масштабирования, в которых один сервер поддерживает тысячи клиентов с сотнями одновременных операций синхронизации. Это тестирование привело к большому количеству внутренних улучшений производительности, позволяющих поставщикам баз данных Sync Framework работать так же хорошо, как и другие технологии Microsoft, такие как удаленный доступ к данным (RDA), предлагая широкий спектр возможностей, которые конкурируют с комплексными решениями, такими как репликация слиянием. .

person Scott Munro    schedule 31.10.2009