3

(100ms-900ms) の範囲の実行時間ですべてのクエリに対してヒープと計算集約型のプロセスを実行する場合の nio と bio のトレードオフに関する経験はありますか?

4

3 に答える 3

2

覚えておくべきことの1つは、JVM for NIOのバグの報告です。これにより、Jettyがハングし、CPUを100%使用します。したがって、今のところ、この動作が見られる場合は、BIOを使用することをお勧めします。関連リンク:

http://jira.codehaus.org/browse/JETTY-937

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6403933

于 2011-05-24T19:25:41.573 に答える
2

本当の問題は、物理サーバーごとにいくつの同時オープン接続をスケールアップできるようにするかということです (たとえば、サーバー メッセージング プッシュ 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 は非常にエレガントで簡単であることがわかりました。

于 2008-12-28T07:52:54.573 に答える
1

大量のデータを送受信しない限り、CPU に関する考慮事項が支配的になります。java.nio は java.io よりも使いにくいです (JDK 7 の非同期 I/O はその中間になります)。データ量がバッファリングを超える場合は、別のスレッドで I/O を実行することをお勧めします。

于 2008-12-27T21:21:28.280 に答える