ネットワークから Web ページを受信し、HTML の詳細な処理を実行するヘビー スレッド アプリケーションを構築しました。基本的に、すべてのスレッドは、多くのネットワークにバインドされた操作と CPU にバインドされた操作で構成されています。私はそれらを別々のスレッドで実行します (したがって、ほとんどの IO/CPU 使用率を達成します)。
何百万もの URL を処理する必要があるため、seda を実行できません。Camel 2.3 に関しては、デフォルトでサイズが無制限で、しばらくするとメモリ不足になります。seda キューのサイズを厳密に制限することはできますが、そうしないことに決め、代わりに JMS キューを使用します。
同じ数のスレッドで、jprofiler8 を使用した Thread Telemetry の異なる結果が表示されます。違いを確認してください：
jms: キューと比較して seda: キューを使用すると、IO 使用率が大幅に向上する理由を誰かに説明してもらえますか?
あなたのシナリオは少し不明確です。
SEDA は単純に、 BlockingQueueから Exchange をエンキュー/デキューするためのラッパーです。すべてメモリ内、VM 操作内。
JMS キューは、一部の MOM サーバー実装 (Apache ActiveMQ、Apache Qpid、または IBM WebSphere MQ など) に対する単なる API 抽象化です。ただし、JMS キューはトランザクションと共に TCP/IP 上のワイヤ プロトコルを介して使用されるように構築されているため、持続性とセレクターなどの複雑な機能が一緒に使用されます。実行時のサーバー リソースの特性は、もちろん SEDA 実装とは異なります。正確な方法と理由は、さまざまなオプションと、使用している特定の JMS 製品と、他の多くの予測が難しい要因に大きく依存します。
Camel ライブラリを新しいバージョンに更新して、SEDA キューのサイズを制御し、いっぱいになったときにプロデューサーをブロックすることをお勧めします。