MQTT Performance
This page describes the performance characteristics of the MQTT plug-in in OPC Router based on real-world benchmark measurements (see benchmark details).
Factors Affecting Performance
Main Factors
- Round Trip Time (RTT) – Latency between OPC Router and the broker. Has a direct impact on throughput and latency, especially for QoS 1 and QoS 2.
- QoS Level – Determines the number of acknowledgment steps between the client and the broker.
- Connection pooling – Increases throughput during parallel transfers.
- Broker performance – Internal queues, topic filters, and CPU/I/O load.
- Router configuration – Number of transfers per second, enabled options (deduplication, wait-for-transfer, etc.).
Quality of Service (QoS)
| QoS | Description | Communication Phases | Typical RTT | Relative Speed | Typical Local Latency |
|---|---|---|---|---|---|
| 0 | Send without acknowledgment | 1 (Client → Broker) | 0.5 × RTT | very high | < 10 ms |
| 1 | Acknowledgment (PUBACK) | 2 (Client ↔ Broker) | 1 × RTT | medium | 20–80 ms |
| 2 | 4-way handshake (PUBREC/PUBREL/PUBCOMP) | 4 (Client ↔ Broker) | 2 × RTT | low | 40–150 ms |
Network Round Trip Time (RTT)
RTT (Round Trip Time) is the time it takes for a data packet to travel from the OPC Router to the MQTT broker and back again. It depends heavily on the network environment and directly affects the performance of MQTT communication.
| Environment | Typical RTT | Description |
|---|---|---|
| Local (same host) | 0.5–2 ms | Local Mosquitto broker or Docker container on the same machine |
| Local network (LAN) | 1–5 ms | Broker in the same network segment or data center |
| Corporate network (Corp-VPN) | 10–40 ms | VPN- or MPLS-based site connection, additional encryption latency |
| Cloud (hyperscaler) | 30–100 ms | MQTT broker in Azure, AWS, or Google Cloud, depending on region and peering |
| Wide area network (WAN) | 80–250 ms | International or mobile connections, possibly via public networks |
With QoS 1 or QoS 2, the effective transmission time increases linearly with the RTT, since each acknowledgment round requires a full round-trip time.
Connection Pooling
Connection pooling distributes publish operations across multiple parallel MQTT connections, thereby significantly increasing the throughput rate.
| Parameter | Description |
|---|---|
| Min. connections | Minimum number of simultaneously open connections |
| Max. connections | Upper limit for parallel MQTT connections (adjustable up to 100) |
| Idle timeout | Time until inactive connections are closed |
Benefits
- Significantly higher throughput for high-volume transfers
- Load balancing across multiple threads
- Prevention of deadlocks with QoS 1/2
Recommendation
| Scenario | Recommended setting |
|---|---|
| Few transfers / simple telemetry | Disable pool (Single Connection) |
| Medium to high load | Min. = 5, Max. = 50 |
| Very high load or parallel topics | Min. = 10, Max. = 100 |
Real-world benchmark results (local)
Measured with Mosquitto 2.0.22, OPC Router 5.5, Windows Sandbox (i7-13700, 4 GB RAM), 100-byte payload.
| transfer flows | QoS | Avg. Throughput [msg/s] | Max. [msg/s] | Comment |
|---|---|---|---|---|
| 1 | 0 | 64 | 65 | Base load without pool |
| 1 | 1 | 63 | 65 | Hardly any difference from QoS 0 (local) |
| 10 | 0 | 640 | 650 | Linear scaling with number of connections |
| 10 | 1 | 616 | 648 | Slight overhead due to PUBACK |
| 50 | 0 | 2670 | 3117 | Strong parallelization, slight fluctuations |
| 100 | 0 | 4230 | 5286 | Maximum tested rate without pool |
| 50 (Pool) | 0 | 3025 | 3230 | +13% increase due to pooling |
| 100 (Pool) | 0 | 5556 | 6118 | Highest measured throughput |
All values are from local benchmarks (RTT ≈ 1 ms). In real networks, throughput decreases proportionally to RTT, as each QoS acknowledgment requires additional round-trip time.
Optimization Recommendations
- QoS 0 for fast, non-critical data (e.g., telemetry, measurement values)
- QoS 1 as the default for delivery reliability with acceptable performance
- QoS 2 only when absolute accuracy is required
- Enable connection pooling for high concurrency or MQTT 5-batch transfers
- Disable deduplication if data frequently remains the same
- Cycle Time (expert setting): reduce only if CPU load remains stable
- Adjust Keep Alive / timeout values to the network’s RTT