巨大なファイル/データベースを準備して書き込むサーバーを作成しています。
バッファ サイズとして 8192 を使用している多くの場所で、ストリームの読み取りおよび書き込み関数を使用しました。
TCP ソケットから大量の入力も読み取っています。
サービスが展開される VM の構成がどうなるかわかりません。
サーバーに最適なバッファ サイズを決定できる組み込み関数はありますか?
質問する
2195 次
3 に答える
3
これは私自身もよく疑問に思いました。しかし、結局のところ、適用すべき一般的なルールがあるとは思いません。それは常にあなたの特定のニーズに帰着します。
経験則として、バッファーが大きいほど、ファイル システムまたはデータベースへのラウンドトリップが少なくて済みます。これは一般的に、ほとんどの場合に最適です。
ただし、他のアプリケーションを作成せずに、システムが一度にメモリに読み込むことができるデータの量は、個々の環境に大きく依存します。一部のモバイル デバイスは、オーバー ザ トップ サーバー ハードウェアなどとは仕様が異なる場合があります。
他に考慮すべきことは、ネットワーク帯域幅やその他の共有リソース、およびアクションに対するパフォーマンスへの影響です。
たとえば、何千もの画像ファイルを含むプロジェクトで、何度か試行した結果、idela のバッファー サイズが約 1 MB であることがわかりました。それより小さいサイズの画像については、ファイル サイズと同じバッファ サイズを使用しました。あなたのシナリオでは、これはもちろん当てはまりません。
Microsoft のパフォーマンス エキスパートである Rico Mariani は、パフォーマンスのためのプログラミングの最も重要な 10 の側面を挙げています。
于 2012-09-03T10:45:09.930 に答える
2
The critical factor is not the size of the application's buffer but the size of the socket send and receive buffers, which must be >= the bandwidth-delay product of the link. Any increase above that should yield zero benefit; any decrease below it will become visible in suboptimal bandwidth. Application buffers have a role to play in reducing system calls but 8192 is normally quite enough for most purposes, especially networking ones.
于 2012-09-04T10:03:29.033 に答える
2
これは、本番環境でのスループット、通信チャネルの使用率、および接続の安定性に依存します。
私の観点からは、ここでの最善の方法は、上記の要因に応じてバッファ サイズを変更する適応アルゴリズムを作成することです。
更新します。
85000 バイト以上のバッファを使用する場合は注意してください。このようなバッファーは、可能な限り再利用する必要があります (LOH の動作のため)。
于 2012-09-03T09:52:16.943 に答える