4

BlazeDS はサーブレットとして実装されるため、同時ユーザー数はおよそ数百に制限されます。

サーブレット 3 をサポートする最新の Web コンテナー (Tomcat 7、GlassFish/Grizzly、Jetty など) を使用して NIO エンドポイントを作成し、同時ユーザー数を数千に増やすことができるのでしょうか?

これは有効で実用的な解決策ですか? 誰もが本番環境でこれを行いますか?

これの成熟したバージョンのようなもの: http://flex.sys-con.com/node/720304 これが当時非常に重要だった場合、なぜ今 (サーブレット 3 が広く利用可能になったとき) しようとする努力がなかったのですか? NIO エンドポイントを実装しますか? （注、私はここでは初心者なので、何か不足している場合は遠慮なく言ってください）

NIO の利点: http://www.javalobby.org/java/forums/t92965.html

そうでない場合、それぞれが BlazeDS のインスタンスを持つロード バランサーと複数のアプリケーション サーバーは、推奨されるソリューションですか (LCDS への移行などを除く)?

4

1 に答える 1

3

GraniteDS と非同期サーブレット

GraniteDS は、私の知る限り、リアルタイム メッセージング用の非同期サーブレットを実装する唯一のソリューションです。データプッシュ。この機能は、Servlet 3 コンテナ (Tomcat 7、JBoss 7、Jetty 8、GlassFish 3 など) だけでなく、特定の非同期サポートを備えた古いコンテナやその他のコンテナ (Tomcat 6/CometProcessor、WebLogic 9+/AbstractAsyncServlet など) でも利用できます。など）

他のソリューションにはこの機能がない (BlazeDS) か、RTMP を使用する (LCDS、WebORB、Clear Toolkit の最新バージョン)。RTMP の実装についてはあまり言えませんが、BlazeDS は同期サーブレット モデルしか使用していないため、スケーラブルなリアルタイム メッセージングの実装が明らかに不足しています。

何千もの同時ユーザーを処理する必要がある場合は、スケーラビリティと堅牢性をさらに向上させるために、GraniteDS サーバーのクラスターを作成することもできます (たとえば、このビデオを参照してください)。

非同期サーブレットのパフォーマンス

非同期サーブレットと従来のサーブレットのスケーラビリティは、何度かベンチマークされており、印象的な結果が得られています。たとえば、Jetty ブログの次の投稿を参照してください。

非 NIO または非継続ベースのサーバーでは、10,000 人の同時ユーザーを処理するために約 11,000 のスレッドが必要になります。Jetty は、この数の接続をわずか 250 スレッドで処理します。

古典的な同期モデル:

  • 10,000 の同時ユーザー -> 11,000 のサーバー スレッド。
  • 1.1の比率。

コメット非同期モデル:

  • 10,000 の同時ユーザー -> 250 のサーバー スレッド。
  • 0.025 の比率。

この種の比率は、他の非同期実装 (Jetty ではない) から大まかに予測できます。また、プレーン テキストの HTTP 要求の代わりに Flex/AMF3 を使用しても、結果が大きく変わることはありません。

非同期サーブレットを使用する理由

各リクエストがすぐに処理される場合は、従来の (同期) サーブレット モデルを使用できます。

    request -> immediate processing -> response

データ プッシュの問題は、HTTP プロトコルには真の「データ プッシュ」が存在しないことです。サーバーは、データを送信するためにクライアントへの呼び出しを開始できず、リクエストに応答する必要があります。そのため、Comet の実装は別のモデルに依存しています。

    request -> wait for available data -> response

同期サーブレット処理では、各要求は 1 つの専用サーバー スレッドによって処理されます。ただし、データ プッシュ処理のコンテキストでは、このスレッドはほとんどの場合、利用可能なデータを待っているだけで、サーバー リソースを大量に消費しながら何もしません。

非同期処理のすべての目的は、サーブレット コンテナーがこれらの (多くの場合) アイドル状態のスレッドを使用して、他の着信要求を処理できるようにすることです。そのため、アプリケーションでリアルタイム メッセージング機能が必要な場合に、スケーラビリティの面で劇的な改善が期待できます。

このメカニズムを説明している Web 上のリソースは他にもたくさんあります。Comet でググってみてください。

于 2012-02-03T15:36:57.833 に答える