さまざまなサーバーのスキャンを実行するサービスがあります。問題のネットワークは巨大になる可能性があります（数十万のネットワークノード）。
ソフトウェアの現在のバージョンは、私たちが設計したキューイング/スレッドアーキテクチャを使用していますが、これは機能しますが、効率的ではありません（特に、ジョブが適切に処理されない子を生成する可能性があるため）
V2が登場し、TPLの使用を検討しています。理想的には適しているようです。
私はこの質問を見てきました。その答えは、TPLが処理できるタスクに制限がないことを意味します。私の簡単なテスト（100,000個のタスクをスピンアップしてTPLに渡す）では、TPLはかなり早い段階でメモリ不足の例外を除いてバーフしました（十分に公平です-特に私の開発ボックスで）。
スキャンにはさまざまな時間がかかりますが、5分/タスクが適切な平均です。
ご想像のとおり、巨大なネットワークのスキャンは、強力なサーバーであっても、かなりの時間がかかる可能性があります。
スキャンジョブ（Dbに格納されている）を複数のスキャンサーバー間で分割できるフレームワークはすでに用意されていますが、問題は、特定のサーバーのTPLに作業をどの程度正確に渡す必要があるかです。
TPLのキューのサイズを監視し、それが数百エントリを下回った場合に（たとえば）それを補充できますか？これを行うことの欠点はありますか？
また、スキャンを一時停止する必要がある状況にも対処する必要があります。これは、すでに部分的に処理されている可能性のあるタスクをキャンセル/リセットするよりも、TPLに作業を渡さない方が簡単なようです。
すべての初期タスクは、任意の順序で実行できます。親が実行を開始した後に子を実行する必要がありますが、親が子を生成するため、これが問題になることはありません。子供は任意の順序で実行できます。このため、現在、子タスクはTPLに直接生成されるのではなく、Dbに書き戻されることを想定しています。これにより、必要に応じて他のサーバーが「盗む」ことができます。
誰かがこのようにTPLを使用した経験がありますか？知っておく必要のある考慮事項はありますか？