MQTT Broker Latency by Region: How to Measure and Choose a Location

MQTT broker latency by region matters because the physical distance between your devices and the broker sets a floor that no amount of tuning can remove. This guide explains where MQTT latency comes from, shows you how to measure round-trip times from your own sites with a short script, and gives a practical method for choosing where your broker should run.

Where MQTT Latency Comes From

End-to-end latency for an MQTT message, from a sensor publishing to a subscriber receiving it, is the sum of several parts:

Region choice mostly affects propagation and routing. Light in optical fiber travels at roughly two thirds of its speed in vacuum, which works out to about 1 millisecond of round-trip time for every 100 kilometres of fiber path, before any routing detours. Real network paths are rarely straight lines, so measured times are higher. A device in one continent talking to a broker on another will always pay for that distance on every round trip.

Connection setup multiplies round trips

Latency hurts most at connect time. Before the first message flows, a TLS-protected MQTT client needs a TCP handshake, a TLS handshake and an MQTT CONNECT/CONNACK exchange. TLS 1.3 needs one round trip for its handshake, TLS 1.2 typically two. That means several round trips before the first publish, which is noticeable for devices that wake from deep sleep, connect, publish and disconnect. For always-connected devices, setup cost is paid once and steady-state round-trip time matters more.

QoS adds acknowledgement round trips

A QoS 0 publish is fire-and-forget. QoS 1 waits for a PUBACK, and QoS 2 needs a four-step exchange. The message reaches subscribers at about the same time, but the publisher spends longer waiting, which matters for clients with limited in-flight windows. Our article on MQTT QoS levels covers the trade-offs.

How to Measure MQTT Latency from Your Sites

Generic latency maps are a useful starting point, but your own measurements from your own sites are what count. Measure at three levels.

Level 1: Network round-trip time

From a machine at the device site, run:

# ICMP round trip (may be blocked by some networks)
ping -c 20 broker.connectmq.com

# Per-hop view of the path, useful to spot detours
mtr --report --report-cycles 20 broker.connectmq.com

# TCP connect time to the MQTT TLS port
time nc -z -w 5 broker.connectmq.com 8883

The nc line only measures a raw TCP connect; the MQTT-level script below gives the more useful TLS and protocol numbers.

Level 2: MQTT connect and publish round trip

This Python script, using paho-mqtt 2.x, measures time to CONNACK over TLS and then the round trip of messages published and received by the same client. Run it from each site you care about.

# mqtt_rtt.py - measure MQTT connect time and publish/receive round trip
import statistics
import sys
import threading
import time
import uuid

import paho.mqtt.client as mqtt

HOST = sys.argv[1] if len(sys.argv) > 1 else "broker.connectmq.com"
PORT = 8883
SAMPLES = 30
run_id = uuid.uuid4().hex[:8]
TOPIC = f"connectmq/demo/{run_id}/rtt"

connected = threading.Event()
received = threading.Event()
rtts = []
sent_at = 0.0

def on_connect(client, userdata, flags, reason_code, properties):
    client.subscribe(TOPIC, qos=0)

def on_subscribe(client, userdata, mid, reason_codes, properties):
    connected.set()

def on_message(client, userdata, msg):
    rtts.append((time.perf_counter() - sent_at) * 1000)
    received.set()

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                     client_id=f"rtt-{run_id}", protocol=mqtt.MQTTv5)
# For a private broker, add credentials:
# client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set()
client.on_connect = on_connect
client.on_subscribe = on_subscribe
client.on_message = on_message

t0 = time.perf_counter()
client.connect(HOST, PORT, keepalive=30)
client.loop_start()
if not connected.wait(15):
    sys.exit("could not connect and subscribe")
print(f"connect + TLS + subscribe: {(time.perf_counter() - t0) * 1000:.0f} ms")

for i in range(SAMPLES):
    received.clear()
    sent_at = time.perf_counter()
    client.publish(TOPIC, str(i), qos=0)
    if not received.wait(5):
        print("timeout on sample", i)
    time.sleep(0.2)               # stay well under 10 msg/s on the public broker

client.loop_stop()
client.disconnect()
if rtts:
    rtts.sort()
    print(f"publish->receive RTT over {len(rtts)} samples: "
          f"median {statistics.median(rtts):.1f} ms, "
          f"p90 {rtts[int(len(rtts) * 0.9) - 1]:.1f} ms, max {rtts[-1]:.1f} ms")

Because the same client publishes and receives, the result is one full round trip through the broker, which is a good proxy for device-to-backend latency when your backend sits close to the broker. The script uses the public MQTT test broker with a random topic, so it runs without an account.

Level 3: Candidate regions you control

To compare locations before committing, start a small virtual machine in each candidate cloud region, install Mosquitto with TLS, and run the same script against each from each site. That gives you a matrix of real numbers instead of assumptions.

Turning Measurements into a Decision

Collect results in a table like this, using medians and a high percentile rather than single pings:

Then apply these rules:

1. Weight by importance, not just device count. A control loop at one site may matter more than hundreds of dashboards elsewhere.
2. Include your backend. If databases and services run in one cloud region, a broker far from them adds latency to every message consumed.
3. Look at p90 and maximum, not only median. Jitter matters for anything interactive.
4. Check residency requirements. Data protection rules may decide the region before latency does; see MQTT data residency.
5. Consider partitioning. If sites are spread across continents and need low latency, separate brokers per region may beat one central broker.
6. Remember that latency is rarely the only factor. Cost, residency and operational simplicity often outweigh a few milliseconds for telemetry that is read by humans.

Choosing a ConnectMQ Deployment Location

ConnectMQ offers several deployment models, and location works differently in each:

• Serverless (Free and Paid): your broker runs on ConnectMQ's shared cluster. Run the measurement script from your sites against it to see whether the round-trip time meets your needs.
• Dedicated: an isolated cluster for your workload. Discuss location options with the team and bring your measurement table.
• BYOC: the broker runs in your own cloud account, so it can sit in the region where your other systems already live. Confirm supported providers and regions with the team when planning; our BYOC MQTT broker guide covers the model.
• Self Managed Enterprise: you place it wherever you run your own infrastructure.

For most telemetry and monitoring workloads, a well-placed broker in the same broad geography as the devices is enough. For tight control loops, keep them local at the edge and use the cloud broker for supervision, reporting and integration. Our real-time digital twin latency article discusses that split in more detail.

Common Latency Pitfalls

• Measuring once from the office. Measure from the actual device networks, especially cellular sites.
• Blaming the broker for Wi-Fi. Run the network tests first; access networks often contribute more delay than distance.
• Reconnecting for every message. Deep-sleep devices pay several round trips per wake-up; keep sessions open where power allows.
• Placing subscribers far from the broker. A backend in another region doubles the distance every message travels.
• Ignoring DNS. Slow resolvers add delay to every new connection; cache results on gateways.

Measure Your Latency on ConnectMQ

ConnectMQ is a hosted MQTT broker with Serverless, Dedicated and BYOC deployment options, so you can match location to your sites and systems. Create a free Serverless broker at app.connectmq.com, no credit card required, run the script from your sites, and use the results to choose your production setup. The cloud MQTT broker guide covers the rest of the hosting decision, and how to scale an MQTT broker covers capacity.

Frequently Asked Questions

How much does region choice affect MQTT latency?

Distance sets a minimum round-trip time of roughly 1 millisecond per 100 kilometres of fiber, and real routes add more. For devices on another continent, region choice usually dominates the network part of latency.

What is the best way to measure MQTT broker latency?

Run an MQTT-level test from the device site that times connect, TLS and a publish-to-receive round trip, and collect medians and high percentiles over many samples.

Does TLS make MQTT slower?

TLS adds round trips at connect time but very little cost per message afterwards. Keep connections open where possible so the handshake is paid once.

Can I choose where my ConnectMQ broker runs?

With BYOC the broker runs in your own cloud account, so you choose the region within the options the team supports. For Dedicated deployments, discuss location with the team.