MQTT Performance Tests: Fan-In

Fan-in

Fan-in is the many-to-few case: a large number of publishers, each on its own topic, feeding a small pool of subscribers that share the load through a shared subscription. Every message is delivered to exactly one subscriber, so the broker does no delivery amplification — what this measures is ingest at scale plus the cost of dispatching across a shared subscription group.

50,000 publishers on 50,000 topics at one message per second, so 50,000 messages/second in aggregate, consumed by 500 subscribers sharing $share/benchmark/test/#. QoS 1, 16-byte payload, 30 minutes. The scenario mirrors the Open MQTT Benchmark Suite's singlenode-sharesub-50K-500-50K-50K case so the figures can be read against those published there; see the Test Environment page for hardware, tuning and method.

Reading the results

• XMQ holds the full rate at 217µs, and holds it flat: the ten interval averages span 215–218µs across the whole thirty minutes. It does so on 2.7 of the 8 vCPUs it is pinned to — a third of its own allowance, an eighth of the machine — in 242 MB.
• Mosquitto also holds the rate, at 379 ms, and is the one overloaded case here whose latency improves over the run rather than diverging (946 ms down to 145 ms), on a single core. The cost is memory: 31.4 GB peak on a 40 GB host. This configuration leaves the in-flight and queued message limits unbounded, so the early backlog is absorbed as heap rather than as dropped messages.
• EMQX did not reach the offered rate here: 41,958/s of 50,000/s, with latency climbing from 226 ms to 260 s, while saturating all 16 vCPUs. That does not match EMQX's own published result for this scenario (50,000/s at 2.51 ms), and the explanations within our control were checked and ruled out: its configuration follows EMQX's performance tuning guide, the load generator sat at 275% of the 1600% available, memory was never constrained, and the hardware is equivalent. What remains is the broker version (5.8.9 here against 5.0.21 there) and the load generator. It is reported as a result for this version under this harness, not as a general statement about EMQX — particularly since Mosquitto held the same rate on one core while EMQX saturated thirteen, which points at something specific to shared-subscription dispatch in this build.