MQTT Broker Load Testing Tool

Anyone deploying MQTT at scale — smart-campus sensors, factory telemetry — eventually asks 'how many clients can my broker take before latency explodes?', and answering it against production is risky. This project builds a load-testing studio around a virtual broker engine that models the dynamics honestly: per-client publish rates ramp up over a configurable window, offered load is compared against a throughput ceiling with jitter, latency follows a queueing curve (flat until ~85% load, then climbing), and connection floods inject accept errors. Live canvas charts show throughput, p50/p95/p99 latency, connections and QoS mix; scenario checks (sustained throughput, p99 bound, loss budget, ramp completion) render pass/fail verdicts from measured series; CSV/JSON export carries the full time series for the report. The engine is a teaching model of broker behavior — documented as such — with a bridge API path for hardware-in-the-loop runs against a real broker.

1. The user configures the virtual broker (endpoint label, throughput capacity, base latency) and the load profile (clients, rate, payload, ramp-up, QoS mix).
2. On start, virtual clients come online along the ramp curve; each publishes at the configured rate with the selected QoS mix.
3. Each 500 ms tick computes offered load (with fan-out amplification in that scenario) against the jittered capacity ceiling; excess is counted as dropped.
4. Latency per tick combines base latency, a queueing term that activates above ~85% utilization, and Gaussian jitter; p50/p95/p99 come from a sliding window.
5. Charts and KPI cards update live; the run-status line shows clients online, offered vs capacity, and elapsed time.
6. On stop (or scenario completion), the verdict engine compares measured sustained throughput, mean p99, loss percentage and ramp completion against targets.
7. Export serializes the verdict table and the full time series to CSV or JSON for the report.

Tech stack:

• JavaScript (ES6+)
• Canvas charting (hand-rolled)
• Queueing latency model
• Sliding-window percentiles
• Scenario engine
• CSV/JSON exporters
• Single-file web app

• [Virtual broker engine] Capacity ceiling, base latency, accept queues and per-client sessions modeled live — no real broker needed for the demo.
• [Live metric charts] Canvas-rendered throughput, p50/p95/p99 latency, connections/errors and QoS-mix donut, updating every 500 ms.
• [Load profile controls] Clients (10–2000), msgs/client/s, payload size, ramp-up time, QoS 0/1/2/mixed — all adjustable mid-session.
• [Three test scenarios] Publish throughput (find the knee), connection flood (2,000 connects in 10 s), subscribe fan-out (delivery amplification).
• [Pass/fail verdicts] Sustained throughput, p99 latency bound, loss budget and ramp completion checked against targets automatically.
• [CSV/JSON export] Full time series plus verdict table exported for the project report.
• [Queueing latency model] Latency stays near base until high utilization, then climbs — the classic knee curve, visible live.

• Single-file load-testing studio (working demo)
• Virtual broker engine source (documented model)
• Scenario definitions (throughput, flood, fan-out)
• User guide: profiles, scenarios, reading verdicts
• Project report PDF (MQTT primer, load-testing theory, queueing model)
• PPT presentation for final review
• Viva Q&A preparation document

• The virtual broker is a teaching model of broker dynamics, not a real MQTT implementation — stated in the UI; it cannot replace testing against a real broker, which the bridge API path supports.
• Latency and loss figures are produced by the model, not measured from hardware — the report labels them as simulation outputs.
• MQTT protocol details ( retained messages, wildcards, auth) are out of scope; the engine models load, not protocol conformance.
• The queueing curve parameters are configurable but approximate; real brokers have additional nonlinearities.
• Payload content is synthetic; the engine varies size, not content semantics.
• Browser timing (500 ms ticks) is approximate under heavy tab load.