あるネットワーク共有から別のネットワーク共有にファイルをコピーするシステムがあります。ファイル自体はそれほど大きくありませんが、コピーされるファイルの数は 20000 単位です。コピー操作を開始する .NET サービス アプリケーションは複数のマシンで実行されますが、ソース フォルダーと宛先フォルダーは同じだ。このプロセスは容認できないほど遅いようです。
これは、ネットワーク I/O とディスク I/O が高いことが原因であると想定しています。
ボトルネックを特定するためのトラブルシューティング手順は何ですか? プロセスを高速化するために、ソフトウェア設計またはハードウェア容量の観点から、どのようなソリューションが考えられるでしょうか。
まず、それがディスクかネットワークかを判断します。書き込み先のディスクから始めます。いくつかのスレッドをスピンアップし、固定サイズのいくつかの異なるファイルにランダム データを書き込む簡単なアプリを作成します。かかる時間を測定します。1 つの大きなファイルと多数の小さなファイルの書き込みを測定します。ディスクの場合は、多くの個別の書き込み操作と低速の RPM ドライブが原因である可能性が最も高くなります。または、不適切に構成されたディスク アレイに書き込んでいる可能性があります。
次に、ネットワークを確認します。ルーターが貧弱または過剰に機能していませんか? すべてのマシンとルーターが速度とネゴシエーションに同意していることを確認してください。ルーターの 100Mbit-FullDuplex とサーバーの 100Mbit-AutoNegotiateは同じものではありません。（これは私たちの場合であり、非常に役立ちました）
Benがコメントしたように、ファイルを圧縮して 1 つの大きなファイルを転送すると役立ちます。この問題があり、実際にファイルをTARしました。圧縮なしで圧縮するよりも高速でした。zip と tar の両方にSharpZipLibを使用しました。
読み取りと書き込みを別々のスレッドでバッファリングすることもできます。私たちにとって、 System.File.Copy は、ネットワーク上でさえ信頼できませんでした。ファイル転送を手動でバッファリングすると、ある程度の改善が見られましたが、複雑さを正当化するには不十分でした.
多くの小さなファイルを処理することは、1 つの大きなファイルで同じ量のデータを処理するよりも常に遅くなります。これは、割り当てテーブルを処理したり、ファイル名の参照を確認したりするなどの追加の処理が必要になるためです。リクエストにネットワーク遅延を追加すると、さらに悪化します。
常に役立つとは限りませんが、Windows ファイル共有を使用するギガビット LAN 上でさえ、ファイルを圧縮し (高速化するために圧縮せずに zip します)、宛先で再度抽出すると、おそらくはるかに高速になります。
Hometoasts の回答は良いですが、ディスクとネットワーク IO のボトルネックの可能性をカバーしているため、私はその回答に投票しました。私は実際には答えではなく回避策を提供しただけです。
でも、実用的で簡単にできることを手伝うことができてうれしいです。:)