私は現在、次のチャットの類推に一致する設定を持つアプリケーションをいじっています。
- チャットは、メモリに保持され、チャット メッセージのリストを含むオブジェクトです。
- チャットは複数のブラウザー ウィンドウでレンダリングされ、更新は a4j:push で取り込まれます
プログラムによるセットアップは次のようになります: メッセージを含むチャット オブジェクトのインスタンスは、異なるセッションの PAGE スコープの seam コンポーネント間で共有されます。これで、任意のセッションが新しいメッセージをポストするとき、つまりチャット オブジェクトを変更するとき、すべての Seam コンポーネントに新しいメッセージが通知され、新しい状態がすべてのクライアントの UI に中継されるようになります。
これを実現するには、次の 3 つの方法が考えられます。
- パラメータとしてチャット ID を持つ Seam のイベント。次に、各コンポーネントが ID をチェックし、メッセージを更新または無視します。
- JMS キューまたは 1 つの JMS トピックで、各コンポーネントがフィルタを使用してチャットだけをリッスンします。
- 共有チャット オブジェクト内の純粋な Java リスナー メカニズム。つまり、各 seam コンポーネントがそれに登録され、通知は純粋で直接的な Java です。
議論のために、チャットの数が多く (数万)、チャット ユーザーの数が少ない (2 ～ 10 としましょう) と仮定します。
それぞれのパフォーマンスはどのようにスケールしますか? Seam でこれを実現し、パフォーマンスを向上させる方法について他に何か提案はありますか?
私が見ているように、(1) は統合されてクリーンになりますが、最終的には、実際にそれを必要とするのはごくわずかな数万のコンポーネントに通知することになります。したがって、おそらくスケーリングしません。
(2) 統合され、JMS プロバイダー (交換可能) のパフォーマンスのみに依存し、変更なしでクラスター化された環境でも動作します。ここでの JMS のパフォーマンスについてはよくわかりません。つまり、1 秒あたり数百のメッセージと、さまざまなフィルターを持つ数千のリスナーが多いかどうかはわかりません。
(3) 必要なコンポーネントのみが通知され、通知は純粋で直接的な Java であるため、高速です。ただし、セッション/コンポーネント/スレッドを横断する何かが行われるため、並行性/アクセスの問題が発生する可能性があります。
(1) と (3) の場合、クラスタリングをサポートするソリューションは、必要に応じて手動で追加する必要があります。