The XMQ cluster has four broker nodes, each on its own AWS c5n.2xlargeinstance (8 vCPU, 21 GiB), in one placement group in us-east-1a. A singlec5n.4xlarge client carries every connection, binding its clients to 29 source addresses. XMQ keeps its cluster state in a dedicated Redis instance and its accounts in PostgreSQL; EMQX 5.8.9 is the last Apache 2.0 release that can form a cluster without a commercial licence. Both products run MQTT 5 on port 1884, QoS 1, with a 16-byte payload.

The comparison covers only brokers that can form a cluster in their community editions. XMQ and EMQX 5.8.9 both do so without a commercial licence; brokers whose community editions do not support clustering were not tested here, because a single-node result would not answer the question this page asks.

Every scenario starts on a freshly restarted cluster, with the other broker stopped. Each node is a separate process on a separate machine, so the numbers include the cluster links, not just one broker's event loop. Latency is end-to-end delivery; memory and CPU are the sum of the four nodes. See the Test Environment page for the single-node method and the client.

The four throughput scenarios use MQTT clean sessions (clean_session=true). They measure routing and delivery throughput, and a clean session leaves no state to carry when a node goes down, so those runs say nothing about session migration. That behaviour is measured separately, below.

Throughput is only half of what a cluster has to do. What happens when a node dies under load — whether the survivors keep serving and the victim comes back — is on the Cluster Survivability page.

500K Connections

500,000 clients connecting at 5,000/s, spread evenly over the four nodes: 125,000 each.

Client: AWS c5n.4xlarge, 29 bound source addresses, xmq_scn 1.0.0, no CPU affinity

Broker ▲	Version	Messages	Achieved rate	Avg latency	CPU	Avg RAM	Median RAM	Max RAM
EMQX	5.8.9	500,000	4,545/s(below target)	1.7ms	405% mean / 568% peak (cluster total)	6.51 Gb	6.77 Gb	9.87 Gb (cluster total)
XMQ	1.0.0	500,000	4,545/s(below target)	544us	104% mean / 130% peak (cluster total)	1003 Mb	977 Mb	1.65 Gb (cluster total)

EMQX

XMQ

Delivery latency over the test

Broker memory (RSS) over the test

Latency uses a logarithmic axis: the brokers differ by several orders of magnitude in this scenario, and a linear axis would flatten the faster ones onto the baseline. Hover the chart for per-interval values.

Fan-In 50K

50,000 publishers send one QoS 1 message each second to a cluster-wide shared subscription with 500 subscribers.

Client: AWS c5n.4xlarge, 29 bound source addresses, xmq_scn 1.0.0, no CPU affinity

Broker ▲	Version	Messages	Achieved rate	Avg latency	CPU	Avg RAM	Median RAM	Max RAM
EMQX	5.8.9	29,991,993	49,986/s	1.5ms	1835% mean / 2140% peak (cluster total)	12.4 Gb	13.5 Gb	14.23 Gb (cluster total)
XMQ	1.0.0	29,995,082	49,991/s	465us	646% mean / 745% peak (cluster total)	413 Mb	431 Mb	440 Mb (cluster total)

EMQX

XMQ

Delivery latency over the test

Broker memory (RSS) over the test

Fan-Out 250K

Five publishers send 250 messages/second in total to 1,000 subscribers: 250,000 deliveries/second.

Client: AWS c5n.4xlarge, 29 bound source addresses, xmq_scn 1.0.0, no CPU affinity

Broker ▲	Version	Messages	Achieved rate	Avg latency	CPU	Avg RAM	Median RAM	Max RAM
EMQX	5.8.9	74,997,654	249,992/s	1.7ms	1198% mean / 1420% peak (cluster total)	1.73 Gb	1.73 Gb	1.73 Gb (cluster total)
XMQ	1.0.0	74,998,001	249,993/s	1.2ms	447% mean / 526% peak (cluster total)	210 Mb	210 Mb	210 Mb (cluster total)

EMQX

XMQ

Delivery latency over the test

Broker memory (RSS) over the test

Point-to-Point 50K

50,000 publishers and 50,000 subscribers, one topic each, 2 messages/second per publisher: 100,000 messages/second.

Client: AWS c5n.4xlarge, 29 bound source addresses, xmq_scn 1.0.0, no CPU affinity

Broker ▲	Version	Messages	Achieved rate	Avg latency	CPU	Avg RAM	Median RAM	Max RAM
EMQX	5.8.9	59,904,187	99,840/s	944us	2257% mean / 2718% peak (cluster total)	7.51 Gb	8.17 Gb	8.34 Gb (cluster total)
XMQ	1.0.0	59,938,679	99,897/s	497us	1283% mean / 1545% peak (cluster total)	825 Mb	892 Mb	900 Mb (cluster total)

EMQX

XMQ

Delivery latency over the test

Broker memory (RSS) over the test

Stateful session migration

This check is separate from the four throughput scenarios and does not use a clean session. A subscriber with clean_session=false and a fixed client id connected to node-c. That node was then killed with kill -9, as in the survivability test: no handover and no lease released. While it was down, 10,000 unique QoS 1 messages were published at 100/s from node-a. The same client id then reconnected to node-d.

Measured	Result
Messages published while the owner node was down	10,000
Delivered after reconnecting to another node	10,000
Missing	0
Duplicates	0
Also received by a live clean subscriber on `node-b`	10,000
Result	PASS

Every message published during the outage reached the persistent session on the node it reconnected to, with no loss and no duplicates. The live subscriber shows that publishing itself continued while the owner was gone. QoS 1 is at-least-once, so a retransmission would have been allowed; none occurred.

Connection-rate headroom (XMQ only)

The 500K scenario above paces 5,000 connections per second, because that is a pace both products sustain and a comparison has to be like for like. This is the other question: how fast can XMQ accept connections before something in the stand gives. The same 500,000 clients, at four rising paces, each on a freshly restarted cluster.

Pace asked for	Sustained	Median connect	Result
10,000/s	10,000/s	617 µs	held
20,000/s	19,540/s	527.9 ms	at the knee
40,000/s	21,552/s	6366.5 ms	saturated
80,000/s	21,436/s	9339.0 ms	saturated

XMQ holds 10,000/s with sub-millisecond connect latency. At 20,000/s the clients still all connect, but half a second of queue has built up behind them, and above that the stand settles near 21,000/s however fast the scenario asks. Neither the brokers nor the client are the constraint: each broker stays under one core of its eight and the client's 16 vCPUs sit mostly idle. The connection path is: it makes about seven round trips to the shared Redis per connection — 3.5 million commands for 500,000 clients, measured with INFO commandstats — and a round trip to that Redis is about 0.1 ms on this stand. With four listener threads per node, that is roughly 4,500 connections/s per node, or about 18,000 for the cluster, which is where the ladder lands. Redis itself stays near half a core: the cost is the number of round trips, not its CPU. Taking session registration off the connect path, or batching it, is what would raise this ceiling.


Source code on GitHub
Credits:	The XMQ web site is provided by Linotex.	The XMQ and SPTK Windows installers are created with Advanced Installer free Open-Source license.