RabbitMQ with Web MQTT Plugin vs. Node.js : Performance and Memory Usage Comparison

Introduction

In applications that require real-time, efficient data communication, two commonly used technologies are RabbitMQ with the Web MQTT Plugin and Node.JS (Socket.IO). RabbitMQ with the Web MQTT Plugin allows for communication using the MQTT protocol over WebSockets, while Node.JS (Socket.IO) provides a JavaScript runtime that efficiently handles events in real-time. This article compares the performance and memory usage of RabbitMQ with the Web MQTT Plugin and Node.JS (Socket.IO), particularly for handling 36 events such as notifications, data reloads, and queue management. It also analyzes whether this setup is optimal or requires further adjustments.

---

Overview of RabbitMQ with Web MQTT Plugin

What is RabbitMQ with Web MQTT Plugin?

RabbitMQ is a message broker that supports multiple protocols, including MQTT. The Web MQTT Plugin in RabbitMQ enables clients to communicate with the broker via WebSockets using the MQTT protocol. This is particularly useful for web-based applications that need real-time, two-way communication, such as notifications or data queuing.

Key Functions of RabbitMQ with Web MQTT Plugin

1. WebSocket Communication: Allows web-based clients to use MQTT over WebSockets, enabling direct communication between the server and browser clients.
2. Queue and Topic Management: Supports queue and topic configurations for effective message traffic management.
3. Retained Messages: Stores the last message so that newly connected clients can receive the latest information without re-requesting.
4. High Scalability for Lightweight Messages: Ideal for applications sending real-time notifications with low latency, like data reloads and notification queues.

---

Overview of Node.JS (Socket.IO)

What is Node.JS (Socket.IO)?

Node.JS (Socket.IO) is a JavaScript runtime built on Chrome's V8 engine, designed to handle non-blocking I/O operations. In this context, server.js is used to manage notification events, data reloads, and queues via WebSocket or HTTP protocols, depending on the application requirements.

Key Functions of Node.JS (Socket.IO)

1. Non-Blocking I/O: Allows handling multiple requests simultaneously without blocking other operations, ideal for event-driven applications.
2. Event-Driven Architecture: Reduces resource consumption by running code only when specific events occur.
3. Two-Way Communication: Node.JS (Socket.IO) is well-suited for real-time applications that require continuous two-way communication between the client and server via WebSocket.
4. Efficiency and Responsiveness: Efficiently handles large numbers of I/O-based connections, such as managing notifications and queues.

---

Challenges and Limitations

RabbitMQ with Web MQTT Plugin

1. Resource Consumption: RabbitMQ, especially with the Web MQTT Plugin, can consume a lot of memory and CPU to handle high message volumes. In this test, RabbitMQ showed a CPU usage of about 5.2%, which is relatively high but reasonable for a message broker.
2. Latency under High Load: Under extremely high loads, there might be a slight latency in message delivery, which can impact applications heavily reliant on real-time performance.
3. More Complex Configuration: Compared to Node.JS (Socket.IO), RabbitMQ with Web MQTT Plugin requires more initial configuration, especially for setting up queues, topics, and bindings.

Node.JS (Socket.IO)

1. Single-Threaded: Node.JS (Socket.IO) uses a single thread, so CPU-intensive operations can become a bottleneck. In testing, CPU usage reached 50.5%, which is high for a single-threaded application and may cause delays.
2. Memory Leaks: If not managed properly, a Node.JS (Socket.IO) application can experience memory leaks, especially in long-running applications with high event activity.
3. Dependency on External Libraries: Node.JS (Socket.IO) often relies on many third-party libraries which, if not maintained, could affect overall performance.

---

Performance Analysis with Glances

Overview of the Processes

• RabbitMQ with Web MQTT Plugin:
  • CPU usage: 5.2%
  • Memory usage: 2.8% (5.97 GB Virtual, 887 MB Resident)
  • Uptime: 18 hours and 26 minutes
• Node.js (server.js):
  • CPU usage: 50.5%
  • Memory usage: 0.4% (1.04 GB Virtual, 257 MB Resident)
  • Uptime: 4 hours and 1 minute

These numbers give an initial impression of how each service is consuming resources.

CPU Usage Comparison

• RabbitMQ is relatively light on CPU, only consuming 5.2%, even though it is managing 36 events (notifications, data reloads, and queue management tasks). This low CPU usage is characteristic of RabbitMQ, as it is optimized for message handling and asynchronous communication.
• Node.js (server.js) is consuming significantly more CPU, at 50.5%. This high usage suggests that server.js may be handling more compute-intensive tasks, possibly related to managing WebSocket connections, processing requests, or handling real-time data. This high CPU usage could impact the server’s performance under higher load or when additional applications are running concurrently.

Memory Usage Comparison

• RabbitMQ shows higher memory usage with 887 MB resident memory, which is reasonable for a messaging broker handling continuous WebSocket connections and MQTT messaging through the Web MQTT Plugin. Its virtual memory footprint (5.97 GB) is high, but this is typically due to pre-allocation and not actual memory in use.
• Node.js (server.js) has a much lower memory footprint, with only 257 MB resident memory. Node.js applications generally have a small memory footprint but can grow based on the complexity of tasks. Its relatively low memory usage here suggests it is well-optimized for handling tasks, though the high CPU usage may indicate some inefficiencies in CPU-bound tasks.

Uptime and Stability

• RabbitMQ has an uptime of over 18 hours, and it’s using minimal CPU, indicating that it is stable and efficient over longer periods.
• Node.js (server.js) has only been running for 4 hours but is consuming a large percentage of the CPU. If this CPU usage trend continues, it could become a bottleneck and may require restarting or optimization, especially for a production environment that expects high uptime.

Implications on System Performance

• RabbitMQ with Web MQTT Plugin appears to be less demanding on the CPU and moderate in memory usage. This makes it well-suited for applications that require high-throughput messaging with minimal latency. The current resource usage does not seem excessive, but monitoring memory over longer uptime periods is advised, as message brokers can accumulate memory usage with a high volume of persistent messages.
• Node.js (server.js) at 50.5% CPU usage suggests that it could be CPU-bound, which could affect other processes or reduce system responsiveness under high load. If server.js handles WebSocket connections, optimizing the code for asynchronous tasks or offloading some processes could reduce CPU usage. High CPU usage in Node.js might also suggest the need for load balancing across multiple instances, especially if the server needs to scale to handle more events.

Recommendations for Optimization

• RabbitMQ: Although RabbitMQ's memory usage is moderate, monitoring is recommended to ensure it doesn't grow unbounded over time, especially with increased event volumes.
• Node.js (server.js):
  • Optimize CPU Usage: Review code for any CPU-intensive operations or synchronous code that might benefit from asynchronous handling.
  • Benchmark and Load Test: Conduct stress tests to see if server.js CPU usage increases further with more concurrent events. This could help identify specific code bottlenecks.
  • Scaling: Consider horizontal scaling for server.js by running multiple instances behind a load balancer, especially if high CPU usage persists under typical workloads.

Latency

• RabbitMQ with Web MQTT Plugin: Generally has low latency, especially in real-time communication for lightweight messages, which is ideal for notification and data reload scenarios.
• Node.JS (Socket.IO): Low latency, but high CPU load can introduce delays, especially if the application handles CPU-intensive events.

---

Conclusion

RabbitMQ with Web MQTT Plugin is a good choice for applications that require real-time message handling, particularly for the 36 events including notifications, data reloads, and queue management. With around 5.2% CPU usage, RabbitMQ is stable for high message delivery loads, especially when low latency and two-way communication are needed.

Node.JS (Socket.IO) is suitable for applications needing an event-driven architecture with two-way communication. However, with CPU usage reaching 50.5%, applications may face limitations in scenarios requiring high CPU processing. Therefore, solutions like clustering or worker threads could be considered if usage continues to grow.

Overall:

• RabbitMQ with Web MQTT Plugin: Highly recommended for applications with large messaging and notification needs. It also simplifies managing connections and messages through WebSockets efficiently.
• Node.JS (Socket.IO): Ideal for web applications that require fast responses and two-way communication but may require further adjustments to reduce CPU load.

With performance analysis through Glances, both technologies have demonstrated results by capturing the highest CPU usage values from each process, which is quite suitable for this scenario. However, regular monitoring is necessary to prevent spikes in CPU or memory usage that could impact the overall system performance.

please correct me if I'm wrong 😁

Note : If you have any suggestions for testing, please comment below, and feel free to recommend other tools for real-time communication between the client and server 😊.

Documentation:
https://www.rabbitmq.com/docs/web-mqtt
https://socket.io/docs/v4/