クライアントからサービスにファイルを送信するメソッドを持つサービスがあります。クライアントとサービスを同じマシンで実行し、送信したいファイルがローカルマシンにもある場合、すべてが非常に高速に動作することに気付きました。
ただし、クライアントとサービスは同じマシンにありますが、ファイルは別のコンピューターにあるため、速度が非常に遅くなります。
あるコンピュータから別のコンピュータにファイルをコピーすると、速度が速いので、帯域幅に問題はないようです。
tcpとbasicHttpBindingを使用しようとしましたが、結果は同じです。
この問題は、クライアントが他のコンピューターにある場合に送信しようとしたときにも発生します。
ありがとう。
編集：タスクマネージャーを開いた場合、コンピューターの[ネットワーク]タブでクライアントを実行すると、ネットワークの使用率が約0.5％であることがわかります。なんで？
大きなファイルを送信するためのWCFは最適な方法ではありません。これは、WCFには多くのレイヤーとオーバーヘッドがあり、それらが合計されてファイル送信の遅延が発生するためです。さらに、バイトのチャンクを継続的に読み取り、応答に書き込むためのWCFサービスを作成していない可能性があります。File.ReadAllを実行してから文字列全体を返すと、サーバーで大量の同期読み取り、大量のメモリ割り当てが発生し、大きな文字列がWCFバッファーに書き込まれ、IISに書き込まれる可能性があります。バッファなど。
大きなファイルを送信する最良の方法は、HttpHandlerを使用することです。Response.TransmitFileを使用してファイルを転送するだけで、IISはファイルを最適な方法で送信します。それ以外の場合は、常に一度に8kを読み取り、応答ストリームに書き込み、8kの書き込みごとにFlushを呼び出すことができます。
奇妙な理由でHttpHandlerにアクセスできない場合は、WCFコードを見せてもらえますか？
別物。IISが図に示されている場合、単純に不可能なパフォーマンスを期待している可能性があります。まず、ファイルをWebサイトで直接ホストし、WebClient.downloadStringを実行してファイルをダウンロードする場合に、IISがファイルを送信するのにかかる時間を測定する必要があります。
もう1つは、どのようにダウンロードしていますか？ブラウザ経由？またはクライアント側のコードを介して？ファイル全体を1回のショットで送信し、それを文字列に保持しようとしている場合も、クライアント側のコードは最適ではない可能性があります。たとえば、WebClient.DownloadStringは最悪のアプローチです。