我有一个Windows服务,它使用任务并行库(TPL)并行执行大量任务。这将被扩展为处理与外部服务器上的SQL Server交互的任务。
TPL应该善于测量负载并为任务分配正确数量的并行线程。有没有办法让它知道外部SQL Server实例的负载?在本地服务器上为每个任务运行的实际代码非常小,但对数据库的调用可能非常繁重。
我是否不太可能因为TPL看到本地服务器有大量免费资源,或者有一种已知的方法来处理这个问题而最终导致我的服务因数据库而被请求停止?
答案 0 :(得分:3)
TPL没有什么可以帮助你解决这个问题。 TPL是关于管理/最大化本地应用程序的CPU负载。它不知道SQL加载,更不用说在另一台机器上了。
那就是说,如果你想变得疯狂,有一个名为TaskScheduler
的可扩展性点。从理论上讲,implement a custom TaskScheduler
可以监视SQL服务器上的负载,并且只有在负载处于某个定义的阈值时才会调度要执行的任务。
老实说,我不认为这是解决问题的正确方法。管理像SQL Server这样的共享资源的负载与TPL旨在解决的完全不同。你最好只是确保你设计你的应用程序,这样它就不会通过负载测试来滥用SQL服务器,找到一个最佳位置并配置你的应用程序不会超出这些范围。从那里开始,您的DBA将决定SQL服务器基础架构本身的正确解决方案,以管理该应用程序的需求以及任何其他外部负载。
答案 1 :(得分:0)
如果您在客户端应用程序中并行化数据访问功能,您会发现下一个瓶颈是SQL Server连接池。
答案 2 :(得分:-1)
TPL擅长对数据进行分区,就像测量负载一样,该任务是由您的操作系统决定的(实际上它非常擅长)。因此,这更像是一个配置问题,而不是开发问题。 (您的SQL Server实例的优先级是否高于您的服务?)。