MQTT Performance Tests: Message Persistence

Persistence

Everything on the other test pages runs in memory. This page measures what it costs to make delivery survive a broker restart: every session is persistent, every message is QoS 1, and each delivery is recorded in Redis. What a failure can still lose depends on the configuration - see Persistence.

The scenario is point-to-point, the same shape as the in-memory point-to-point page: each publisher has its own subscriber on its own topic, so the broker does no fan-out and what is measured is the per-message cost of routing plus the cost of persisting it. Both client groups connect with clean_session off, so a run at 60K holds 120,000 persistent sessions. Each publisher sends one message per second with a 16-byte payload. Redis runs on the broker host, and the broker starts against an empty database.

This configuration answers a particular need, and is not the one most deployments want. Persistence earns its cost where a message that never arrives is worse than a message that arrives late: commands to equipment that is intermittently connected, orders and transactions, anything a subscriber must receive even if it was offline when the message was sent, or if the broker restarted between the two. For live telemetry, metrics and status streams — where the next reading supersedes the last and a gap costs nothing — persistence buys nothing, and the in-memory figures on the other test pages are the ones that apply.

It is worth setting the numbers below against that. Workloads that genuinely need durable delivery are usually counted in messages per device per minute rather than per second, so the rates measured here are well clear of what they ask for. The ceiling matters when durable and high-volume traffic share one broker, and the two can be separated: only sessions connecting with clean_session off and messages sent at QoS 1 or above pay for persistence at all, so a broker can carry both without the fast traffic paying the durable traffic's cost.

XMQ 0.9.19, Durable, 60K messages/second

AWS c5n.4xlarge for the broker and for the client, 60,000 publishers and 60,000 subscribers - 120,000 persistent sessions. Redis 8 on the broker host in the Durable mode (appendfsync everysec), max_queued_writes 1000, 10 minutes.

Average latency per minute. Hover the chart for per-interval values.

Reading the results

• Latency is flat: 210–211us every minute. No backlog grows behind the broker - this is a rate it sustains, not one it survives.
• The broker is not near its limit. XMQ used 216% CPU on average (378% peak) of 16 vCPU, and 598 Mb of memory for 120,000 sessions.
• What a crash can lose is bounded. max_queued_writes 1000 is under 20 ms of traffic at this rate; Durable Redis adds at most one second on a power failure. See Persistence.