Web MQTT プラグインを使用した RabbitMQ と Node.js : パフォーマンスとメモリ使用量の比較

はじめに

リアルタイムで効率的なデータ通信を必要とするアプリケーションでは、Web MQTT プラグインを使用した RabbitMQ と Node.JS (Socket.IO) の 2 つのテクノロジが一般的に使用されます。 RabbitMQ と Web MQTT プラグインを使用すると、WebSocket 経由で MQTT プロトコルを使用した通信が可能になり、Node.JS (Socket.IO) はイベントをリアルタイムで効率的に処理する JavaScript ランタイムを提供します。この記事では、特に通知、データのリロード、キュー管理などの 36 のイベントの処理について、RabbitMQ と Web MQTT プラグインおよび Node.JS (Socket.IO) のパフォーマンスとメモリ使用量を比較します。また、この設定が最適であるか、またはさらなる調整が必要かどうかも分析します。

Web MQTT プラグインを使用した RabbitMQ の概要

Web MQTT プラグインを使用した RabbitMQ とは何ですか?

RabbitMQ は、MQTT を含む複数のプロトコルをサポートするメッセージ ブローカーです。 RabbitMQ の Web MQTT プラグインを使用すると、クライアントは MQTT プロトコルを使用して WebSocket 経由でブローカーと通信できるようになります。これは、通知やデータ キューイングなど、リアルタイムの双方向通信を必要とする Web ベースのアプリケーションに特に役立ちます。

Web MQTT プラグインを使用した RabbitMQ の主な機能

1. WebSocket 通信: Web ベースのクライアントが WebSocket 経由で MQTT を使用できるようにし、サーバーとブラウザ クライアント間の直接通信を可能にします。
2. キューとトピックの管理: 効果的なメッセージ トラフィック管理のためのキューとトピックの構成をサポートします。
3. 保持メッセージ: 新しく接続したクライアントが再要求せずに最新情報を受信できるように、最後のメッセージを保存します。
4. 軽量メッセージの高いスケーラビリティ: データのリロードや通知キューなど、低遅延でリアルタイム通知を送信するアプリケーションに最適です。

Node.JS (Socket.IO) の概要

Node.JS (Socket.IO) とは何ですか?

Node.JS (Socket.IO) は、Chrome の V8 エンジン上に構築された JavaScript ランタイムで、ノンブロッキング I/O 操作を処理するように設計されています。このコンテキストでは、server.js は、アプリケーションの要件に応じて、WebSocket または HTTP プロトコル経由で通知イベント、データのリロード、キューを管理するために使用されます。

Node.JS (Socket.IO) の主な機能

1. ノンブロッキング I/O: 他の操作をブロックすることなく複数のリクエストを同時に処理できるため、イベント駆動型アプリケーションに最適です。
2. イベント駆動型アーキテクチャ: 特定のイベントが発生した場合にのみコードを実行することで、リソースの消費を削減します。
3. 双方向通信: Node.JS (Socket.IO) は、WebSocket を介したクライアントとサーバー間の継続的な双方向通信を必要とするリアルタイム アプリケーションに適しています。
4. 効率と応答性: 通知やキューの管理など、大量の I/O ベースの接続を効率的に処理します。

課題と限界

Web MQTT プラグインを使用した RabbitMQ

1. リソース消費: RabbitMQ、特に Web MQTT プラグインを使用すると、大量のメッセージを処理するために大量のメモリと CPU を消費する可能性があります。このテストでは、RabbitMQ は約 5.2% の CPU 使用率を示しました。これは比較的高いですが、メッセージ ブローカーとしては妥当です。
2. 高負荷時の遅延: 負荷が非常に高い場合、メッセージ配信にわずかな遅延が発生する可能性があり、リアルタイム パフォーマンスに大きく依存するアプリケーションに影響を与える可能性があります。
3. より複雑な構成: Node.JS (Socket.IO) と比較して、Web MQTT プラグインを備えた RabbitMQ では、特にキュー、トピック、バインディングのセットアップに、より多くの初期構成が必要です。

Node.JS (Socket.IO)

1. シングルスレッド: Node.JS (Socket.IO) は単一スレッドを使用するため、CPU を集中的に使用する操作がボトルネックになる可能性があります。テストでは、CPU 使用率が 50.5% に達しました。これはシングルスレッド アプリケーションとしては高く、遅延が発生する可能性があります。
2. メモリ リーク: 適切に管理されていない場合、特にイベント アクティビティが多く長時間実行されるアプリケーションで、Node.JS (Socket.IO) アプリケーションでメモリ リークが発生する可能性があります。
3. 外部ライブラリへの依存: Node.JS (Socket.IO) は多くの場合、多くのサードパーティ ライブラリに依存しており、メンテナンスされていない場合、全体的なパフォーマンスに影響を与える可能性があります。

一目でわかるパフォーマンス分析

プロセスの概要

• Web MQTT プラグインを使用した RabbitMQ:
  • CPU 使用率: 5.2%
  • メモリ使用量: 2.8% (5.97 GB 仮想、887 MB 常駐)
  • 稼働時間: 18 時間 26 分
• Node.js (server.js):
  • CPU 使用率: 50.5%
  • メモリ使用量: 0.4% (1.04 GB 仮想、257 MB 常駐)
  • 稼働時間: 4 時間 1 分

これらの数値は、各サービスがリソースをどのように消費しているかについての第一印象を与えます。

CPU 使用率の比較

• RabbitMQ は、38 個のイベント (通知、データのリロード、キュー管理タスク) を管理しているにもかかわらず、CPU 使用量が比較的軽く、消費量は 5.2% のみです。 RabbitMQ はメッセージ処理と非同期通信用に最適化されているため、この低い CPU 使用率は RabbitMQ の特徴です。
• Node.js (server.js) は、50.5% と大幅に多くの CPU を消費しています。この使用率の高さは、server.js が、おそらく WebSocket 接続の管理、リクエストの処理、またはリアルタイム データの処理に関連する、より計算集約的なタスクを処理している可能性があることを示唆しています。この CPU 使用率の高さは、高負荷下や追加のアプリケーションが同時に実行されている場合にサーバーのパフォーマンスに影響を与える可能性があります。

メモリ使用量の比較

• RabbitMQ は、887 MB の常駐メモリでより高いメモリ使用量を示しています。これは、継続的な WebSocket 接続と Web MQTT プラグインを介した MQTT メッセージングを処理するメッセージング ブローカーにとっては妥当な値です。仮想メモリのフットプリント (5.97 GB) は高くなりますが、これは通常、実際に使用されているメモリではなく、事前割り当てによるものです。
• Node.js (server.js) のメモリ使用量ははるかに低く、常駐メモリは 257 MB のみです。 Node.js アプリケーションのメモリ使用量は一般に小さいですが、タスクの複雑さに応じてメモリが増加する可能性があります。ここでのメモリ使用量が比較的低いことは、タスクの処理に適切に最適化されていることを示唆していますが、CPU 使用率が高いことは、CPU に依存するタスクの非効率性を示している可能性があります。

稼働時間と安定性

• RabbitMQ の稼働時間は 18 時間以上で、使用する CPU は最小限であり、長期間にわたって安定していて効率的であることを示しています。
• Node.js (server.js) は 4 時間しか実行されていませんが、CPU の大部分を消費しています。この CPU 使用率の傾向が続くと、ボトルネックになる可能性があり、特に高い稼働率が期待される実稼働環境では、再起動または最適化が必要になる可能性があります。

システムパフォーマンスへの影響

• Web MQTT Plugin を使用した RabbitMQ は、CPU への要求が低く、メモリ使用量も適度であるようです。そのため、遅延を最小限に抑えた高スループットのメッセージングを必要とするアプリケーションに最適です。現在のリソース使用量は過剰ではないようですが、メッセージ ブローカーは大量の永続メッセージでメモリ使用量を蓄積する可能性があるため、より長い稼働時間にわたってメモリを監視することをお勧めします。
• CPU 使用率が 50.5% の Node.js (server.js) は、CPU バウンドである可能性を示唆しており、他のプロセスに影響を与えたり、高負荷時にシステムの応答性が低下したりする可能性があります。 server.js が WebSocket 接続を処理する場合、非同期タスクのコードを最適化するか、一部のプロセスをオフロードすると、CPU 使用率が削減される可能性があります。 Node.js の CPU 使用率が高い場合は、特により多くのイベントを処理するためにサーバーを拡張する必要がある場合、複数のインスタンス間で負荷分散する必要があることを示唆している可能性があります。

最適化の推奨事項

• RabbitMQ: RabbitMQ のメモリ使用量は中程度ですが、特にイベント量が増加した場合に、時間の経過とともに際限なく増加しないように監視することをお勧めします。
• Node.js (server.js):
  • CPU 使用率の最適化: CPU を大量に使用する操作や、非同期処理の恩恵を受ける可能性のある同期コードのコードを確認します。
  • ベンチマークと負荷テスト: ストレス テストを実施して、同時イベントが増えると、server.js の CPU 使用率がさらに増加するかどうかを確認します。これは、特定のコードのボトルネックを特定するのに役立ちます。
  • スケーリング: 特に一般的なワークロードで高い CPU 使用率が続く場合は、ロード バランサーの背後で複数のインスタンスを実行して、server.js の水平スケーリングを検討してください。

レイテンシ

• Web MQTT プラグインを使用した RabbitMQ: 一般に、特に軽量メッセージのリアルタイム通信において遅延が低く、通知やデータのリロード シナリオに最適です。
• Node.JS (Socket.IO): 遅延は低いですが、CPU 負荷が高いと、特にアプリケーションが CPU を集中的に使用するイベントを処理する場合に遅延が発生する可能性があります。

結論

RabbitMQ with Web MQTT Plugin は、リアルタイムのメッセージ処理、特に通知、データのリロード、キュー管理を含む 36 のイベントを必要とするアプリケーションに適しています。 CPU 使用率が約 5.2% である RabbitMQ は、特に低レイテンシーと双方向通信が必要な場合に、高いメッセージ配信負荷に対して安定しています。

Node.JS (Socket.IO) は、双方向通信を備えたイベント駆動型アーキテクチャを必要とするアプリケーションに適しています。ただし、CPU 使用率が 50.5% に達すると、高い CPU 処理が必要なシナリオではアプリケーションが制限に直面する可能性があります。したがって、使用量が増加し続ける場合は、クラスタリングやワーカー スレッドなどのソリューションが検討される可能性があります。

全体:

• Web MQTT プラグインを使用した RabbitMQ: 大規模なメッセージングと通知のニーズがあるアプリケーションに強く推奨されます。また、WebSocket を介した接続とメッセージの管理が効率的に簡素化されます。
• Node.JS (Socket.IO): 高速応答と双方向通信を必要とする Web アプリケーションに最適ですが、CPU 負荷を軽減するためにさらなる調整が必要な場合があります。

Glances によるパフォーマンス分析により、どちらのテクノロジーも各プロセスから最高 CPU 使用率の値を取得することで結果を実証しました。これはこのシナリオに非常に適しています。ただし、システム全体のパフォーマンスに影響を与える可能性のある CPU またはメモリ使用量の急増を防ぐために、定期的な監視が必要です。

間違っていたら訂正してください?

注: テストに関する提案がある場合は、以下にコメントしてください。また、クライアントとサーバー間のリアルタイム通信のための他のツールをお気軽にお勧めください。

ドキュメント:
https://www.rabbitmq.com/docs/web-mqtt
https://socket.io/docs/v4/

以上がWeb MQTT プラグインを使用した RabbitMQ と Node.js : パフォーマンスとメモリ使用量の比較の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。