Webからrabbitmqに接続するかどうかを決定しようとしています：
ソリューション 1. Rabbitmq ストンプ プラグイン + Rabbitmq Web ストンプ プラグイン + Sockjs
ソリューション 2. amqp nodejs プラグインによる Rabbitmq + nodejs
シナリオ：
a) キューをサブスクライブする Web アプリが 1 つある b) そのキューに書き込みを行う Java アプリが 1 つある c) 解決策 1 で 1 つのブラウザーを開き、解決策 2 で別のブラウザーを開いている
私は両方をテストしましたが、何が起こるかは次のとおりです。
連続して 10.000 メッセージを送信すると、解決策 2 は解決策 1 よりもはるかに高速です。解決策 2 は接続を失うことはありません。解決策 1 ほとんどの場合、(すべてのメッセージを取得する前に) ランダムな時間で接続が失われます。
質問:
ソリューション 1 で更新できる制限構成はありますか?
解決策 1 の問題は、Sockjs によるものですか? ストンププラグイン？ストンプウェブプラグイン？それらのすべて？nodejs を途中で追加すると、rabbitmq に埋め込まれた erlang プラグイン (rabbitmq stomp /rabbitmq web stomp プラグイン) よりもはるかに高速である理由がわかりません。
注: ストンプ プラグインまたはストンプ Web プラグインは死ぬことはありません。常にポートをリッスンし続けます。
私の簡単な説明は、ブラウザーはそれほど多くの連続したメッセージを処理できず、nodejs はこれをうまく処理できますが、rabbitmq Web ストンプはそうではないということです。しかし、単なる推測です。これは正しいです？もしそうなら、どうすれば解決できますか？
解決策 1 は、解決策 2 よりも (レイテンシーにおいても) 優れているべきではありませんか?
注: パブリッシャーに各メッセージの送信の間に 5 ミリ秒の差を追加すると、この問題はなくなり、解決策 1 は解決策 2 のように実行されます (10.000 メッセージの場合)。
回答ありがとうございます。
よろしくお願いします、
エドゥアルド