Two Terms, and Connections Win First

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.

See the relationship before changing it

The figure reads from left to right. The blue card is connected devices. The middle card applies the page rule. The green card is estimated broker cpu. Walk the arrows once: set the input, apply the rule, then read the result with its unit.

Walk the arrows. Connections and fan-out scale together, even for a quiet fleet.

Derive the baseline in four named moves

1. 1

   Name the input. The chapter baseline is 1000 devices.

2. 2

   Name the relationship. CPU = 0.01 x (0.3 x devices) + 0.005 x devices

3. 3

   Substitute with units. 0.01 x 300 + 0.005 x 1,000 = 8.00%

4. 4

   Read the result. Keep the unit beside the value. Use it only inside the technical boundary on this page.

Predict, then change connected devices

Try Predict the direction of CPU = 0.01 x (0.3 x devices) + 0.005 x devices. Test another connected devices, then compare estimated broker cpu.

Connected devices

1000 devices

Chapter baseline

Estimated broker CPU

Observe Connections and fan-out scale together, even for a quiet fleet. Reset connected devices to 1000 and compare estimated broker cpu.

Explain Connections and fan-out scale together, even for a quiet fleet.

Check yourself

What should you do before trusting a moved-control result?

Answer: Predict its direction, apply the shown relationship, keep the units, and reset to the worked baseline.

What does this small model leave out?

Answer: Only connected devices moves here. Field effects named in the technical boundary stay fixed.

Honesty note. This teaching model changes only connected devices. It is not a field prediction.

TryChoose Check derivation for 1,000 sensors at 0.1 message/s with 3 subscribers per topic.

ObserveBroker load splits into 3% routing and 5% connection CPU at 1,000 devices, then reaches 80% after a 10x fleet increase.

ExplainSubscriber fan-out multiplies routed messages, but the 0.005-per-connection term already exceeds routing at 1,000 devices and remains the larger scaling cost.

Ready: use the stated baseline inputs, then compare each displayed result.

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.

Technical boundaries. Broker scheduling, retransmission, keep-alive loss, TCP behavior, queue pressure, and reconnect storms are omitted from the fixed connection-plus-message CPU formula.