Benchmarking Message Brokers for IoT Edge Computing: A Comprehensive Performance Study

Abstract

Asynchronous messaging is a cornerstone of modern distributed systems, enabling decoupled communication for scalable and resilient applications. Today's message queue (MQ) ecosystem spans a wide range of designs, from high-throughput streaming platforms to lightweight protocols tailored for edge and IoT environments. Despite this diversity, choosing an appropriate MQ system remains difficult. Existing evaluations largely focus on throughput and latency on fixed hardware, while overlooking CPU and memory footprint and the effects of resource constraints, factors that are critical for edge and IoT deployments. In this paper, we present a systematic performance study of eight prominent message brokers: Mosquitto, EMQX, HiveMQ, RabbitMQ, ActiveMQ Artemis, NATS Server, Redis (Pub/Sub), and Zenoh Router. We introduce mq-bench, a unified benchmarking framework to evaluate these systems under identical conditions, scaling up to 10,000 concurrent client pairs across three VM configurations representative of edge hardware. This study reveals several interesting and sometimes counter-intuitive insights. Lightweight native brokers achieve sub-millisecond latency, while feature-rich enterprise platforms incur 2-3X higher overhead. Under high connection loads, multi-threaded brokers like NATS and Zenoh scale efficiently, whereas the widely-deployed Mosquitto saturates earlier due to its single-threaded architecture. We also find that Java-based brokers consume significantly more memory than native implementations, which has important implications for memory-constrained edge deployments. Based on these findings, we provide practical deployment guidelines that map workload requirements and resource constraints to appropriate broker choices for telemetry, streaming analytics, and IoT use cases.

Figures (8)

• Figure 1: Pub/sub architecture for IoT and distributed systems. Publishers send data to named topics; a central broker routes messages to subscribers, decoupling producers from consumers.
• Figure 2: Experimental scenarios evaluated in this study. Each path from start to end represents one test scenario. For instance, the solid black path represents the scenario in which MQTT–Mosquitto is evaluated with 10,000 clients on a VM with 4-vCPU, 8-GB RAM configuration while measuring throughput.
• Figure 3: Experimental testbed architecture. The Workload Generator Machine runs benchmarking tool (mq-bench) to spawn publisher/subscriber clients that send and receive messages to/from the broker container hosted on the Broker Execution Machine within a VM.
• Figure 4: Architecture of mq-bench. Orchestration scripts invoke the CLI to spawn Publisher and Subscriber roles. Core services handle metrics collection, rate limiting, and result export.
• Figure 5: Median latency with error bars (min to P95) across payload sizes. The y-axis uses a logarithmic scale.