3

TIBCO EMS を介して要求/応答サービスを提供するサーバー側プロジェクトに取り組んでおり、このサービスのスケーラビリティと低遅延をアーカイブするためのベスト プラクティスに関するアドバイスを探しています。私は .NET でこれを行っていますが、TIBCO EMS はおそらく JMS 仕様を実装しているため、他の JMS 実装やプラットフォーム (Java) に関するアドバイスが適切であると思います。

現在、1 つの Connection、1 つの Session、1 つの Consumer を使用し、その 1 つの Consumer でコールバックを使用してメッセージをリッスンしています。各要求はコールバック スレッドで処理され、異なるキュー (ただし同じセッション) で同期的に応答します。これは機能しますが、スケーリングしているようには見えません。高いトランザクション レートでも CPU 負荷は無視できますが、リクエストのレイテンシは増加し続けます。

EMSがコールバックに単一のスレッドを使用しているため、処理時間と応答の送信に必要な時間が発生しているため、他のリクエストの処理がブロックされていると思いますが、これをスケーリングする最良の方法は何ですか?

1 つの方法は、受信したスレッド プールで着信要求の実際の処理をすぐにスケジュールすることです。これは迅速な修正であり、スケーリングされますが、追加のレイテンシが発生し、セッションの使用に関するスレッドの問題が発生します。もう 1 つは、多数の Session オブジェクト、または Connection オブジェクトを使用することでしょうか? 誰でもこれを行うためのベストプラクティスについてアドバイスをいただけますか?私はそれがより一般的な使用パターンの1つであるに違いないと思います...

4

2 に答える 2

1

メッセージの処理は、確認応答モードと並列セッションの数の影響を受けます。

あなたの言うことから、あなたは1つのセッションだけを使用し、次々に処理（および応答）した後にメッセージを確認（クライアント確認）するように思えます。

これは、自動確認応答（受信中にメッセージを確認する）を使用したり、複数のセッションを並行して使用したりすることで高速化できます。

さらに、EMSは、「プリフェッチカウント」と呼ばれるパラメータによってメッセージのプッシュを高速化できます。これにより、キューから新しいメッセージをフェッチする時間が短縮されます。（EMSのドキュメントを参照してください）。

遅い答えですが、私はそれが役立つことを願っています;）

于 2013-03-03T23:38:22.740 に答える
1

2 段階のキューイング プロセスが必要です。コールバックはできる限り少なくする必要があり、私の好みのオプションは、単にメッセージをローカル Queue<T> にエンキューすることです。この Queue は複数のローカル スレッドからアクセスでき、使用可能なアイテムをキューから取り出して処理し、JMS キューイング プロセスを続行できるようにすることで、大量のレイテンシを排除します。

結果を適切な消費者に返すには、少し同期を行う必要がありますが、それは比較的簡単なはずです。

于 2011-11-16T11:35:23.453 に答える