0

現在よりも高速に多数の小さなファイルを処理できるように、WCF クライアント/サーバーを改善したいと考えています。

ネットワーク経由でファイルを移動するための WCF クライアントとサーバーを作成しました。

クライアントからサーバーに呼び出しを行い（ダウンロードするファイルの名前をパラメーターとして送信）、サーバーにストリームを返させることで機能させます

簡単な例:

//CLIENT CODE>>
Stream stream = syncService.GetStream(fileName);
//<<CLIENT CODE

//SERVER CODE>>
public Stream GetStream(string fileName)
{
   string filePathOnServer = ServerService.Service1.SERVER_FILES_PATH + fileName;
   return File.OpenRead(filePathOnServer);
}
//<<SERVER CODE

複数のファイルを取得する必要がある場合は、GetStream を再帰的に呼び出し、クライアント マシンのファイルにストリームを保存します。少数の大きなファイルを移動する場合は問題なく動作します。私が抱えている問題は、サイズに関係なく、1 つのファイルをダウンロードするオーバーヘッドが約 1/10 秒であることです。したがって、膨大な数の 1Kb ファイルをダウンロードしたい場合、基本的に最大 10Kb に制限されます。

誰かが別の実装について提案してくれることを願っています。サーバーからストリームのリストを返そうとしましたが、WCF ではこれが許可されないことがわかりました。

ファイルを圧縮せずにこれを実行できる必要があります。

連結された複数のストリームで構成された 1 つのストリームを返すことを検討していましたが、より良いアプローチがあるかどうかはわかりません。

4

1 に答える 1

3

List<string>ファイル名のコレクション（つまりまたは ）を受け入れるようにWCFメソッドを変更してから、string[]それらをパックします。SharpZipLibが ZIP ファイルの生成に適していることは知っています。

ZIP ファイルをクライアントにストリーミングして戻すと、クライアントはそれを解凍してファイルを処理します。

ファイルごとに 1 回ではなく 1 回の WCF 呼び出しを行うという事実は言うまでもなく、1 つの大きなファイルは、転送が桁違いに速くなり、帯域幅が軽くなるはずです(ネットワーク関連のオーバーヘッドが少なくなるため)。 （大きなボトルネック）。

于 2013-01-03T14:31:11.850 に答える