任務並行庫和外部SQL服務器

我有一個Windows服務，它使用任務並行庫（TPL）並行地執行大量任務。這將被擴展爲處理與外部服務器上的SQL Server交互的任務。任務並行庫和外部SQL服務器

TPL應該很擅長測量負載併爲任務分配正確數量的並行線程。有沒有辦法讓它知道加載到外部SQL Server實例？爲本地服務器上的每個任務運行的實際代碼非常小，但對數據庫的調用可能很重。

我不可能最終與我的服務陷入數據庫與請求，因爲TPL發現本地服務器有大量的免費資源，或者是否有一種已知的方式來處理？

來源

2011-03-10 Christian Rygg

如果有辦法從並行任務中提取數據庫交互，那將是您最好的選擇。 – Steven 2011-03-10 12:14:28

數據庫交互是我想要並行執行的，因此將它解壓縮爲非並行執行將毫無意義... – 2011-03-10 13:10:54

這並不意味着您必須完全順序執行，但是在分離它時，你將擁有更多的控制權。 – Steven 2011-03-10 13:17:02

TPL本身沒有任何東西可以幫助你做到這一點。 TPL是關於管理/最大化本地應用程序的CPU負載。它不知道SQL負載，更不用說在另一臺機器上。

也就是說，如果你想瘋了，有一個擴展點叫做TaskScheduler。理論上，您可以在implement a custom TaskScheduler之間查看SQL服務器上的負載，並且只在該負載處於某個已定義的閾值時才安排要執行的任務。老實說，雖然我不認爲這是解決問題的正確方案。針對共享資源（如SQL服務器）管理負載與TPL旨在解決的問題完全不同。如果你設計的應用程序不會通過加載測試來濫用SQL服務器，找到一個最佳位置並配置你的應用程序不會超出這些範圍，那麼你會更好。從那裏，由您的DBA來決定SQL Server基礎架構本身的正確解決方案，以管理該應用程序的需求以及任何其他外部負載。

來源

2011-03-10 16:40:29

-1

TPL擅長於對數據進行分區，就像測量負載一樣，該任務是爲您的操作系統來確定的（事實上它非常擅長）。因此，這更像是一個配置問題，然後是一個發展問題。（您的SQL Server實例具有更高的優先級，那麼您的服務？）。

來源

2011-03-10 16:12:23 Polity

如果您在客戶端應用程序中並行執行數據訪問功能，則會發現下一個瓶頸是SQL Server連接池。

來源

2011-03-10 16:16:56 DaveRead

我不認爲這將是一個問題，具體取決於硬件配置。然而，它同時運行多個SQL批處理是完全正常的。此外，這個問題似乎意味着已經有一個服務在並行地執行繁重的工作，而不是與SQL綁定 – Polity 2011-03-10 16:34:39

任務並行庫和外部SQL服務器

回答

相關問題