私たちは、tibco-ems JMS を利用してメイン サーバーとの間でクライアント接続に大量のメッセージを渡す高スループット システムを実行しています。いくつかの統計を行った結果、JMS が多くの遅延の原因であることが判明しました。どうすれば tibco JMS のパフォーマンスを向上させることができますか? このトピックに関する適切な議論を提供するリソースはありますか。
2862 次
2 に答える
3
永続性が必要ない場合は、非永続メッセージを使用することも 1 つのオプションです。永続性が必要な場合でも、永続的ではないメッセージを使用する方が良い場合があることに注意してください。クラッシュが発生した場合は、別の回復アクション (すべてのメッセージを再送信するなど) を実行します。
これは、次の場合に関連します。
- クラッシュはまれです (回復には時間がかかるため)
- クラッシュを簡単に検出できます
- 重複メッセージを処理できます (クラッシュ前に配信されたメッセージが正確にわからない場合があります)
EMS は、永続的ではあるが、従来の保証された配信よりも防弾性に劣るいくつかのメカニズムも提供します。
- 「正確に 1 回」のメッセージ配信の代わりに、「少なくとも 1 回」または「最大 1 回」の配信を使用できます。
- アプリケーションがメッセージを要求する前に、クライアントがメッセージをメモリにフェッチするプリフェッチ メカニズムを使用できます。
于 2011-02-23T07:45:27.977 に答える
0
EMS がボトルネックになってはいけません。テストを行ったところ、サーバーで大量のスループットが得られました。
ボトルネックがどこにあるかを判断する必要があります。メッセージのプロデューサーまたはコンシューマーに問題があります。メッセージがキューに積み上げられていますか。
どのタイプのシナリオを実行していますか。
パブ/サップですか、それともリクエストの返信ですか? 一時的なキューが山積みになっていますか。一時キューが多すぎると、パフォーマンスの問題が発生する可能性があります。（ほとんどの場合、何かを適切に閉じなかったために長引く場合）
もしそうなら、永続的なサブスクライバーを持つトピックに公開していますか。トピックをキューにブリッジして、それらから読み取ってみてください。永続的なサブスクライバーは、すべてのメッセージのコピーを持っているユーザーを追跡する必要があるため、パフォーマンスが少し低下する可能性があります。
送信プロセスに 1 つのセッションと、そのセッションを介した複数の呼び出しがあることを確認してください。操作ごとに完全なセッションを開かないでください。可能な限り再利用してください。消費者に対しても同じことを行います。
完了したら、必ず CLOSE してください。EMSは物事を片付けません。そのため、接続を確立してアプリを閉じると、接続は引き続き存在し、リソースを消費します。
クラッシュが発生した場合でもメッセージが失われることに対する許容度を確認してください。Client ack を実行していて、メッセージの処理でクラッシュしてもかまわない場合は、auto に切り替えます。また、(TEMS - WCF 用の Tibco EMS) を使用している場合、セッション確認に問題があると思います。したがって、メッセージはメッセージ全体で処理された場合にのみ存在し、クライアント ACK から Dups が正常に機能したものに切り替えたところ、より適切に機能しました)
于 2013-10-25T04:45:06.243 に答える