jms - ミドルウェア メッセージング ソフトウェアの低パフォーマンスの影響を受ける要因

Question

Web アプリケーションにメッセージング ミドルウェアを組み込むことを計画しています。現在、RabbitMQ、JMS、HornetQ などのさまざまなメッセージング ミドルウェア ソフトウェアをテストしています。このソフトウェアで提供されている例は機能していますが、望ましい結果が得られません。
では、パフォーマンスを向上させるために注目すべき要因はどれでしょうか?
ミドルウェア メッセージング ソフトウェアのパフォーマンスを向上させるために、開発者が注意すべき領域はどれですか?

Answer 1

私は HornetQ のプロジェクト リーダーですが、選択したメッセージ システムに適用できる一般的な回答を提供しようと思います。

私が目にするよくある質問は、単一のプロデューサー/単一のコンシューマーでは期待されるパフォーマンスが得られない理由を尋ねる人々です。

メッセージを送信してすぐに確認を求めている場合は、次のように待機する必要があります。

• クライアントからサーバーへのメッセージ転送
• ディスクに永続化されるメッセージ
• クライアントにコールバックを送信してメッセージの受信を確認するサーバー

同様に、メッセージを受信するときは、サーバーに ACK を送信します。

• ACK はクライアントからサーバーに送信されます
• ACK は保持されます
• サーバーは、コールバックが達成されたことを示すコールバックを返します

また、すべてのメッセージ送信とメッセージ確認の確認が必要な場合は、ディスクの永続化とネットワーク上でのビットの送信にハードウェアが関与しているため、これらの手順を待つ必要があります。

Message Systems は、多くのプロデューサーと多くのコンシューマーでスケールアップしようとします。つまり、多くが生成している場合、すべてのコンシューマーが共有するサーバーで利用可能なリソースをすべて使用する必要があります。

単一のプロデューサーまたは単一のコンシューマーを高速化する方法があります。

• 1 つは、トランザクションを使用することです。したがって、ディスク上で実行するブロックと同期を最小限に抑えながら、サーバーとネットワーク上のラウンドトリップで永続化します。（これは実際にはどのデータベースでも同じです）

• もう 1 つは、コンシューマでブロックする代わりにコールバックを使用することです。(JMS 2 は、HornetQ の ConfirmationHandler に似た Callback を提案しています)。

また、私が知っているほとんどのプロバイダーのドキュメントには、その特定の製品の要件と提案を含むパフォーマンス セクションがあります。各製品を個別に確認する必要があります