マルチスレッドまたはその他の.NETテクノロジを使用して、ネットワーク、ディスク、およびプロセッサを集中的に使用するジョブを実行するプログラムをスケーリングするにはどうすればよいですか？

問題：

1. PDFファイルのバッチをpickup.fileserver（SFTPまたはWindows共有）からローカルハードドライブにダウンロードします（ファイルがダウンロード可能かどうかを確認するために、ここでポーリングが行われます）
2. PDFファイルの処理（サイズ変更、バーコードの適用など）、メタデータファイルの作成、データベースの更新など
3. このバッチをdropoff.fileserver（SFTP）にアップロードします
4. dropoff.fileserverからの応答を待ちます（再度ポーリングが唯一のオプションです）。バッチ応答が利用可能になったら、ローカルHDをダウンロードします。
5. バッチ応答を解析し、データベースを更新して、最後にレポートをpickup.fileserverにアップロードします。
6. すべてのバッチファイルをSANの場所にアーカイブし、手順1に戻ります。

現在のソリューション

このようなバッチが多数発生することが予想されるため、特定の時間間隔でポーリングを継続し、上記の手順を実行できるWindowsサービスを作成しました。一度に1つのバッチを処理します。

懸念

現在のソリューションは機能しますが、利用可能なリソースを最大限に活用していないのではないかと心配しています。確かに改善の余地はたくさんあります。このWindowsサービスをスケーリングして、できるだけ多くのバッチを同時に処理できるようにする方法については、ほとんどわかりません。そして、必要に応じて、異なるサーバーでホストされているこのWindowsサービスの複数のインスタンスを関与させてさらに拡張する方法。

同様のトピックに関するMSDNの記事とSOの回答をいくつか読みました。生産者/消費者パターン（BlockingCollectiong<T>など）の使用に関する提案があります。IOを多用するタスク用にマルチスレッドアプリを作成するのは意味がないと言う人もいます。ここにあるのは、ディスク+ネットワーク+プロセッサを集中的に使用するタスクの組み合わせです。スレッドまたはその他のテクノロジーを使用して、1つのサーバーで利用可能なリソースを最大限に活用し、（必要に応じて）1つのサーバーを超えてさらに拡張する方法を理解する必要があります。

典型的なバッチサイズ

定期的に200〜ファイル、合計サイズ300 MB〜のバッチを取得します。バッチの数は、来年または2年で約50から100に増える可能性があります。年に数回、5kから10kのファイルのバッチを取得します。