Two Terms, and Connections Win First

Ada re-derives this chapter’s own numbers step by step, at full precision

ADA · CALCULATION AUDIT

Two Terms, and Connections Win First

The chapter models a broker’s CPU as two terms: one for routing messages, one for holding connections open. Feed it 1000 sensors each publishing 0.1 messages a second to 3 subscribers and the load is 8% — but that splits into 3% for routing and 5% for the connections. This audit traces both terms as the fleet grows to ask which one bites first, and why connections win.

Companion to the chapter MQTT Publisher-Subscriber Setup — every number here comes from that chapter.

Ada: The load model above adds two terms, and I want to show which one bites first as a deployment grows, because that decides whether you scale for messages or for connections. Take the chapter’s own case: 1000 devices, 0.1 msg/sec each, 3 subscribers per topic.

• Broker input: R_in = 1000 x 0.1 = 100 msg/sec
• Broker output after fan-out: R_out = 1000 x 0.1 x 3 = 300 msg/sec (a 3x amplification)
• CPU: 0.01 x 300 + 0.005 x 1000 = 3 + 5 = 8%

Notice the split already: the routing term is 3% but the connection term is 5%, so at a thousand devices, just holding the connections open costs more than moving their messages. Now scale the fleet tenfold to 10,000 devices at the same rate:

• Output: R_out = 10,000 x 0.1 x 3 = 3000 msg/sec
• CPU: 0.01 x 3000 + 0.005 x 10,000 = 30 + 50 = 80%

Both terms scale with device count, so a 10x fleet is a 10x CPU jump, from 8% to 80%, and one node’s headroom is gone. The lesson the numbers enforce is that a broker’s ceiling is set by connections and fan-out together, not by raw message rate: a quiet fleet that rarely publishes can still saturate a node simply by being large.

Every number above is taken from the chapter’s own material and re-derived step by step.