任务并行库和外部 SQL Server答案

【问题标题】：Task Parallel Library and external SQL Server任务并行库和外部 SQL Server
【发布时间】：2011-03-10 10:55:30
【问题描述】：

我有一个 Windows 服务，它使用任务并行库 (TPL) 并行执行大量任务。这将被扩展为处理与外部服务器上的 SQL Server 交互的任务。

TPL 应该擅长测量负载并为任务分配正确数量的并行线程。有没有办法让它知道外部 SQL Server 实例的负载？在本地服务器上为每个任务运行的实际代码非常少，但对数据库的调用可能非常繁重。

由于 TPL 发现本地服务器有大量空闲资源，我的服务是否不会因请求而导致数据库陷入困境，或者是否有已知的方法来处理这个问题？

【问题讨论】：

如果有办法从并行任务中提取数据库交互，那将是您的最佳选择。
数据库交互是我想要并行执行的操作，因此将其提取到非并行执行中毫无意义...
这并不意味着你必须让它完全按顺序排列，但是当分离它时，你将对它有更多的控制权。

标签： c# .net sql-server task-parallel-library

【解决方案1】：

TPL 没有任何原生功能可以帮助您解决此问题。 TPL 是关于管理/最大化本地应用程序的 CPU 负载。它不知道 SQL 负载，更不用说在另一台机器上。

也就是说，如果您想发疯，有一个称为TaskScheduler 的扩展点。理论上，您可以implement a custom TaskScheduler 监视 SQL 服务器上的负载，并且仅在负载处于某个定义的阈值时才安排任务执行。

但老实说，我认为这不是解决问题的正确方法。针对 SQL 服务器等共享资源管理负载与 TPL 旨在解决的问题完全不同。你最好确保你设计你的应用程序，这样它不会通过负载测试、找到一个最佳位置并配置你的应用程序不会超出这些范围来滥用 SQL 服务器。从那里，您的 DBA 将为 SQL Server 基础架构本身确定正确的解决方案，以管理该应用程序的需求以及任何其他外部负载。

【讨论】：

【解决方案2】：

如果您在客户端应用程序中并行化数据访问功能，您会发现下一个瓶颈是 SQL Server 连接池。

【讨论】：

我认为这不是问题，具体取决于硬件配置。然而，同时运行多个 SQL 批处理当然是完全正常的。此外，这个问题似乎暗示已经有一项服务在并行执行繁重的工作，而不必绑定到 SQL

【解决方案3】：

TPL 擅长对您的数据进行分区，至于测量负载，该任务由您的操作系统来确定（实际上它非常擅长）。因此，这更像是一个配置问题，而不是一个开发问题。（您的 SQL Server 实例的优先级是否高于您的服务？）。

【讨论】：