Библиотека параллельных задач и внешний SQL Server

Question

У меня есть служба Windows, которая выполняет большое количество задач параллельно, используя Task Parallel Library (TPL).Это должно быть расширено для обработки задач, которые взаимодействуют с SQL Server на внешнем сервере.

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

Вероятность того, что моя служба завершит работу базы данных запросом, невелика, потому чтоTPL видит, что на локальном сервере есть множество свободных ресурсов, или есть известный способ справиться с этим?

Answer 1

Нет ничего родного для TPL, которое поможет вам в этом. TPL об управлении / максимизации нагрузки на процессор вашего локального приложения. Он не имеет представления о загрузке SQL, не говоря уже о другой машине.

Тем не менее, если вы хотите сойти с ума, есть точка расширения, называемая TaskScheduler. Теоретически можно реализовать пользовательский TaskScheduler, который может наблюдать за нагрузкой на сервере SQL и планировать выполнение задач только в том случае, если эта загрузка находится на некотором заданном пороге.

Честно говоря, я не думаю, что это правильное решение проблемы. Управление нагрузкой на общий ресурс, такой как сервер SQL, - это совершенно другой зверь, чем то, для чего предназначен TPL. Было бы гораздо лучше, если бы вы просто спроектировали свое приложение таким образом, чтобы оно не использовало сервер SQL самостоятельно, путем нагрузочного тестирования, поиска места и настройки приложения, чтобы оно не выходило за эти пределы. Оттуда ваш администратор БД должен определить правильное решение для самой инфраструктуры сервера SQL, чтобы управлять потребностями этого приложения вместе с любой другой внешней нагрузкой.

Answer 2

Если вы распараллелите функции доступа к данным в своем клиентском приложении, вы обнаружите, что следующим узким местом является пул соединений SQL Server.

Answer 3

TPL хорошо разбивает ваши данные, так как для измерения нагрузки эту задачу должна определить ваша ОС (и на самом деле она довольно хороша в этом).Поэтому это скорее вопрос конфигурации, чем вопрос разработки.(Имеет ли ваш экземпляр SQL Server более высокий приоритет, чем ваша служба?).