.net - HttpWebResponse の応答ストリームの最適なバッファー サイズ

Question

HttpWebResponse.GetResponseStream() からのストリームで使用する最適なバッファ サイズは?

オンラインの例は、256b から 5Kb までさまざまです。何を与える？バッファサイズは状況に応じて変わると思います。もしそうなら、どのようなタイプのバッファサイズを使用する状況は何ですか?

ありがとう。

Answer 1

本当に、それはあまり重要ではありません。

確かに、非常に小さなバッファを使用する場合は、バイトを取得するためにレイヤーを介していくつかの追加の呼び出しを行う必要がある場合があります（ただし、ストリームは少なくともある程度のバッファリングを行っている可能性があります-デフォルトが何であるかはわかりません）。もちろん、非常に大きなバッファを使用すると、メモリが浪費され、断片化が発生します。ここでは明らかにIOを実行しているため、バッファーを微調整することで得られる時間は、IO時間によって支配されます。

原則として、私は2048（2k）と8192（8k）の間で2の累乗で行きます。85,000バイト以上のバッファを使用する場合は、何をしているのかを確認してください（これは「大きなオブジェクト」であり、さまざまなGCルールが適用されます）。

実際、バッファサイズよりも重要なのは、バッファを保持する期間です。ラージオブジェクトヒープの外側にあるオブジェクトの場合、GCは、非常に短命のオブジェクト（Gen 0コレクションが高速）または非常に長命のオブジェクト（Gen 2）の処理に非常に優れています。解放される前に第1世代または第2世代に到達するのに十分な長さのオブジェクトは、比較的コストがかかり、通常、バッファーの大きさよりも心配する価値があります。

最後に、使用しているバッファのサイズが原因でパフォーマンスの問題があると思われる場合は、テストしてください。可能性は低いですが、OSバージョン、ネットワークハードウェア、およびドライバーリリースの奇妙な合流点があり、特定のサイズのバッファーで奇妙な問題が発生している可能性があります。

Answer 2

私の逸話的な経験では、実際には何をしているかによって異なりますが、通常、1024〜4096バイト（1〜4KB、つまり2の累乗）の範囲であれば、同等のパフォーマンスが得られます（4KBが「最高の」数値です）。私は見た）。

基本的に、ストリームから不必要にデータを読み取らないように十分な大きさのバッファーが必要ですが、収穫逓減するほど大きくはありません。バッファが大きすぎる場合（〜MB）、メモリキャッシュミスが増加し、実際にパフォーマンスが低下し始める可能性があります。もちろん、これは実際のH / W（バス速度、キャッシュサイズなど）によって大きく異なりますが、4MBのバッファーが4KBのバッファーよりも遅い場合があるようです（どちらの場合も寿命が長いため、GCはそうではありませんでした）問題）。

Jonathanが指摘しているように、時期尚早の最適化を試す前に、現在の実装をテストしてください。

Answer 3

実際、バッファサイズが小さすぎると問題が発生します。私はそれをテストし、バッファサイズを小さな値に設定すべきではないことを確認しました。私の例では 2048 に設定し、Firefox 1 と比較してダウンロードが非常に遅くなりました (Firefox 1 にはダウンロード セグメンテーションもありません。私の場合と同じです)。

そして、大きなサイズの 409600 に設定した後、ダウンロードは非常に高速になりました。追加の呼び出しにより、オーバーヘッドなどが発生し、ダウンロードが遅くなると思います。おそらくネットワーク レベルでは、バッファがバッファ サイズを超えているため、TCP はパッケージの再送信を要求する必要がありますか? (TCP の仕組みがわからないので、推測にすぎません) ただし、バッファー サイズが小さいと、ダウンロードが確実に遅くなります。私はFirefoxのデフォルトのダウンロード（アドオンとセグメンテーションなし）を使用して実行し、私のクラスを使用してテストしましたが、どちらも大きく異なります。

ここでの接続は静かで高速であるため、ループするたびに約200000バイト（200Kb）を読み取りますが、2つのスレッドを実行した後ははるかに遅くなり、おそらく別のスレッドと共有する必要があります。