Under a sustained QoS 1 backlog the file backend holds roughly twice the memory of the memory backend for the same load.
Measured with an identical local flood (16 publisher connections, --inflight 64, QoS 1, 8 subscriber connections, 256-byte payloads, in-tree release broker):
| Backend |
Peak broker RSS |
file (write-behind) |
933 MB |
memory |
247 MB |
Published and received counts were the same in both arms (~309K published, ~2.88M received), so the difference is retention, not extra work.
Mechanism
A queued message is held by its ClientQueue entry. Pushing it also enqueues a QueueOp::Write carrying its own Arc<QueuedMessage> into the write-behind pipeline, where the pending map keeps it until the settle tick flushes it to disk. While a backlog is draining slowly, the same message body is retained in two places at once.
Suggested change
Have the pending-write entry reference the Arc the ClientQueue entry already holds rather than retaining a second one, or flush pending writes aggressively enough that the second copy is short-lived. Either way a queued message should be retained once.
This is not a correctness defect — memory stays bounded and plateaus — but it roughly doubles the broker's footprint under backlog, which is the regime where the footprint matters most.
Under a sustained QoS 1 backlog the file backend holds roughly twice the memory of the memory backend for the same load.
Measured with an identical local flood (16 publisher connections,
--inflight 64, QoS 1, 8 subscriber connections, 256-byte payloads, in-tree release broker):file(write-behind)memoryPublished and received counts were the same in both arms (~309K published, ~2.88M received), so the difference is retention, not extra work.
Mechanism
A queued message is held by its
ClientQueueentry. Pushing it also enqueues aQueueOp::Writecarrying its ownArc<QueuedMessage>into the write-behind pipeline, where the pending map keeps it until the settle tick flushes it to disk. While a backlog is draining slowly, the same message body is retained in two places at once.Suggested change
Have the pending-write entry reference the
ArctheClientQueueentry already holds rather than retaining a second one, or flush pending writes aggressively enough that the second copy is short-lived. Either way a queued message should be retained once.This is not a correctness defect — memory stays bounded and plateaus — but it roughly doubles the broker's footprint under backlog, which is the regime where the footprint matters most.