This page records what one disposable RunMQTT managed MQTT 5 broker did in a controlled synthetic run. It publishes the method, aggregate output, and limitations so the result can be checked instead of relying on an unqualified performance claim.
The run used no customer data. The script generated unique device identities, topics, and payloads, omitted them from its output, and removed the broker and every related provider resource when the run finished.
Test environment
| Field | Value |
|---|---|
| Execution time | 2026-08-19 12:46:45 UTC |
| Broker | Disposable RunMQTT managed MQTT 5 provider Core |
| Broker region | Global managed endpoint; no production plan tier was selected |
| Client region | us-west |
| Runtime | Node.js 22.23.2 |
| MQTT client | MQTT.js 5.15.2 |
| Protocol | MQTT 5 |
| Data | Generated topics and synthetic payloads only |
| Cleanup outcome | Provider lookup confirmed that all created resources were gone |
Provisioning was measured from submitting the provider Core creation request to the first successful TLS MQTT connection. Connection timing covers five new connections per transport. The controlled message sample used one publisher and one subscriber in the same client region, QoS 1, 200 generated messages, and batches of 20 concurrent publishes.
Measured results
Provisioning and secure connections
- Submission to first TLS connection: 8,062.68 ms.
- MQTT over TLS: 5/5 successful, 630.19 ms minimum, 644.21 ms p50, 649.91 ms p95 and maximum.
- MQTT over secure WebSocket: 5/5 successful, 1,072.63 ms minimum, 1,128.83 ms p50, 1,598.39 ms p95 and maximum.
These are client-observed connection times from this run, not an availability percentage or service-level objective.
QoS and session behavior
| Scenario | Observed result |
|---|---|
| QoS 0 | Publisher sent PUBLISH; subscriber received the message at QoS 0 |
| QoS 1 | Publisher sent PUBLISH, received PUBACK; subscriber received QoS 1 |
| QoS 2 | Publisher completed PUBLISH → PUBREC → PUBREL → PUBCOMP; subscriber received QoS 2 |
| Persistent session | Reconnect returned sessionPresent=true; one queued QoS 1 message was delivered |
| Last Will | Will message was observed at QoS 1 |
| Retained message | A fresh subscriber observed the stored payload, but its packet retain flag was false |
The retained payload replay was observed, but the false retain flag is unexpected for a retained delivery. This run therefore does not claim complete retained-message conformance; applications that depend on that flag should repeat the check with their exact client and broker configuration.
Topic policy allow and deny
Two generated policy templates separated a full observer from a restricted client. The restricted policy allowed only a generated allowed/# subtree.
- Both clients connected.
- The observer subscription was acknowledged.
- The restricted allowed subscription was granted.
- The allowed publish was acknowledged and delivered.
- The denied QoS 1 publish received no acknowledgement within the bounded observation window and was not delivered to the observer.
- The denied subscription returned a rejection signal.
The non-delivery and rejected subscription demonstrate the allow/deny boundary used in this run. no_acknowledgement describes the observed denied-publish behavior; it is not rewritten as an explicit MQTT reason code.
Controlled QoS 1 message sample
| Metric | Result |
|---|---|
| Published messages | 200 |
| Delivered messages | 200 |
| Errors | 0 |
| Concurrency | 20 |
| Elapsed time | 3,393.39 ms |
| Observed throughput | 58.94 msg/s |
| End-to-end latency p50 | 624.92 ms |
| End-to-end latency p95 | 930.89 ms |
| End-to-end latency maximum | 1,075.86 ms |
Latency is measured in one Node.js process from immediately before each publish to receipt by the subscriber. It includes client scheduling, network transit, broker handling, and batch effects. It is not a broker-only latency measurement.
Sanitized aggregate output
This is the aggregate JSON emitted by the completed run. The script does not print credentials, provider Core IDs, device names, topics, or payloads.
{
"schemaVersion": 1,
"environment": {
"broker": "RunMQTT managed MQTT 5 broker",
"brokerRegion": "global",
"clientRegion": "us-west",
"client": "MQTT.js 5.15.2",
"node": "v22.23.2",
"protocolVersion": 5,
"executedAt": "2026-08-19T12:46:45.768Z"
},
"provisioning": { "submittedToFirstTlsConnectionMs": 8062.68 },
"connections": {
"tls": {
"attempts": 5,
"successRate": 1,
"minMs": 630.19,
"p50Ms": 644.21,
"p95Ms": 649.91,
"maxMs": 649.91
},
"wss": {
"attempts": 5,
"successRate": 1,
"minMs": 1072.63,
"p50Ms": 1128.83,
"p95Ms": 1598.39,
"maxMs": 1598.39
}
},
"qos": [
{ "qos": 0, "publisherExchange": ["send:PUBLISH"], "subscriberQos": 0 },
{
"qos": 1,
"publisherExchange": ["send:PUBLISH", "receive:PUBACK"],
"subscriberQos": 1
},
{
"qos": 2,
"publisherExchange": [
"send:PUBLISH",
"receive:PUBREC",
"send:PUBREL",
"receive:PUBCOMP"
],
"subscriberQos": 2
}
],
"persistentSession": { "sessionPresent": true, "queuedMessagesDelivered": 1 },
"retainedMessage": { "observed": true, "retainFlag": false },
"lastWill": { "observed": true, "qos": 1 },
"acl": {
"connectionsObserved": true,
"observerSubscribeOutcome": "acknowledged",
"allowedSubscribeOutcome": "granted",
"allowedPublishOutcome": "acknowledged",
"allowedPublishDelivered": true,
"deniedPublishOutcome": "no_acknowledgement",
"deniedPublishDelivered": false,
"deniedSubscribeOutcome": "rejected"
},
"controlledPerformance": {
"messages": 200,
"qos": 1,
"concurrency": 20,
"delivered": 200,
"errors": 0,
"elapsedMs": 3393.39,
"throughputMessagesPerSecond": 58.94,
"latencyMs": { "p50": 624.92, "p95": 930.89, "max": 1075.86 }
},
"cleanup": { "removed": true }
}
Reproduce the run
Review the public managed profile and lab instructions. In an isolated environment where BAIDU_IOT_AK and BAIDU_IOT_SK are injected by a secret manager, run:
MANAGED_LAB_CONFIRM=run-once \
MANAGED_LAB_CLIENT_REGION=us-west \
pnpm mqtt:managed-lab
The confirmation value is deliberate: the command creates a billable provider resource. A unique Core, two policy templates, and generated devices are created for the run. A finally path removes devices, policies, templates, and the Core, then checks that the Core no longer exists. Treat cleanup.removed=false as a failed run that requires immediate cleanup.
Limits and appropriate use
- This is one dated synthetic run, not a longitudinal availability study.
- Results apply to the listed client, runtime, regions, provider behavior, and configuration.
- No production capacity tier was selected, so this does not establish a plan capacity limit.
- The 200-message sample is intentionally bounded. It is not a stress test, SLA, or capacity guarantee.
- No customer payload, customer topic, production device identity, or real business workload was used.
- The shared public MQTT broker was not used for these private managed-broker measurements.
- Retained payload replay was observed, but the packet flag result needs further compatibility testing.
Use this evidence to reproduce QoS and reconnect behavior, verify least-privilege topic policies, or compare the operational work of managed and self-hosted MQTT. Then review RunMQTT features, compare managed broker pricing, or use the testing-only public broker for a disposable synthetic connectivity check.