Perf Check

Performance check under broker load

The bar

Two brokers, each flooded at around 2000 msg/s across a wide topic tree, with the app connected to both. The UI must stay responsive: topic tree updates, panel interactions, and the graph view must not stutter or leak memory over several minutes. This reproduces what heavy public brokers like test.mosquitto.org do to the app.

Setup (one-time)

# local brokers (macOS)
brew install mosquitto

# python env for the harness (and the rest of the checkout setup)
just setup

scripts/.venv is gitignored, so it does not exist in a fresh agent worktree. just setup (scripts/setup-worktree.sh) creates it with paho-mqtt, or symlinks the main checkout's venv if it cannot, and is safe to re-run. Check scripts/.venv/bin/python -c 'import paho.mqtt' before backgrounding a flood: a missing interpreter fails silently and looks like a broker with no traffic.

Run

Terminals 1 and 2, one broker each:

mosquitto -p 1883
mosquitto -p 1884

Ports 1883/1884 are often taken on this machine (OrbStack binds 1883, other sessions leave mosquitto on 1884). Check with lsof -i :1883 -i :1884 and fall back to 11883/11884; the flood script and the app both accept any port. When running the flood scripts in the background, note their stdout is block-buffered (no tty), so verify throughput with timeout 3 mosquitto_sub -p <port> -t '#' | wc -l instead of reading their output.

Terminals 3 and 4, one flood each (each prints achieved msg/s once per second; confirm it holds the target rate):

scripts/.venv/bin/python scripts/mqtt-flood.py --port 1883 --rate 2000
scripts/.venv/bin/python scripts/mqtt-flood.py --port 1884 --rate 2000

A single flood process tops out around 1,700 msg/s on this machine (paho's python client is the ceiling, not the broker). To hold a true 2,000, run two floods per broker at --rate 1000 rather than trusting the target. Each mqtt-flood.py process connects with its own client id (flood-<port>-<pid>), so two on one broker do not knock each other off. For sparkplug-flood.py, also give each its own --group (for example --group PlantA and --group PlantB; the default is Plant): two floods in the same group publish as the same edge nodes, and their interleaved seq numbers show up as false sequence gaps.

Add --topics 200000 to one of them when the change touches history, the topic tree or memory: high topic cardinality is a separate axis from throughput and several bounds only bite there.

Then run the app (just dev), connect to both brokers (localhost:1883 and localhost:1884), and exercise it for at least a few minutes.

scripts/mqtt-sim.py is the companion script for realistic varied cadences rather than sustained flood; use it when debugging behavior rather than throughput.

What to watch

• Topic tree and message counters keep updating without multi-second freezes.
• Selecting topics and opening the right panel stays instant.
• The graph view (if the change touches it) holds an acceptable frame rate; it has culling/LOD/adaptive-fps logic that should degrade gracefully rather than freeze.
• Memory: watch the process in Activity Monitor for unbounded growth over 5+ minutes.
• CPU settles rather than climbing after you disconnect the floods.

Report concrete observations (achieved msg/s, where it stuttered, memory trend), not just "seems fine".

Reading memory correctly

Two things make RSS misleading, so judge growth only while the floods are still running:

• macOS compresses an idle process's pages. Once the floods stop, RSS collapses (a run holding ~600 MB read as 34 MB) and tells you nothing.
• In-RAM history is capped by DefaultMemoryBudgetBytes, 512 MB per connection, so two connections climb toward ~1 GB of retained messages by design. With Go's default GOGC the process sits well above that. Rising toward the budget is the eviction working, not a leak. What would be a leak is growth that keeps going after the budget is full.