(100ms-900ms) の範囲の実行時間ですべてのクエリに対してヒープと計算集約型のプロセスを実行する場合の nio と bio のトレードオフに関する経験はありますか?
3 に答える
覚えておくべきことの1つは、JVM for NIOのバグの報告です。これにより、Jettyがハングし、CPUを100%使用します。したがって、今のところ、この動作が見られる場合は、BIOを使用することをお勧めします。関連リンク:
本当の問題は、物理サーバーごとにいくつの同時オープン接続をスケールアップできるようにするかということです (たとえば、サーバー メッセージング プッシュ ala コメット パターンをサポートするために - そして最近ではそれをしたくない人はいますか?)。NIO は現実的に 10,000 から 20,000 の範囲に入ります。スレッドは、OS 実装の観点から見ると非常に高価なリソースです (スレッドごとのメモリ消費とコンテキスト切り替えのオーバーヘッド)。そのため、数千の NIO 接続を適度なスレッド プールで維持できます。
MINA のような NIO フレームワークを使用し、ローリング NIO はまったく悪くありません。(実際には非常に簡単です。) 私は独自の NIO を展開し、MINA も組み込みました。MINAは良い方法です。
http://mina.apache.org/testimonials.html
EURid は、2006 年 4 月 7 日の .eu ドメイン名の急増中に MINA を使用しました。最初の 4 時間で 700.000 を超えるドメイン名が登録されました。1 時間後、MINA は 50 万を超える SSL 接続を処理しました。
MINA の速度と安定性は優れていることがわかりました。また、まだ MINA 0.8.1 を使用していますが、API は非常にエレガントで簡単であることがわかりました。
大量のデータを送受信しない限り、CPU に関する考慮事項が支配的になります。java.nio は java.io よりも使いにくいです (JDK 7 の非同期 I/O はその中間になります)。データ量がバッファリングを超える場合は、別のスレッドで I/O を実行することをお勧めします。