Bölgeye Göre MQTT Broker Gecikmesi: Nasıl Ölçülür ve Konum Nasıl Seçilir

Bölgeye göre MQTT broker gecikmesi önemlidir, çünkü cihazlarınız ile broker arasındaki fiziksel mesafe, hiçbir ayarlamanın ortadan kaldıramayacağı bir alt sınır belirler. Bu rehber MQTT gecikmesinin nereden geldiğini açıklıyor, kendi sahalarınızdan gidiş-dönüş sürelerini kısa bir betikle nasıl ölçeceğinizi gösteriyor ve broker'ınızın nerede çalışması gerektiğini seçmek için pratik bir yöntem sunuyor.

MQTT Gecikmesi Nereden Gelir

Bir sensörün yayın yapmasından bir abonenin mesajı almasına kadar bir MQTT mesajının uçtan uca gecikmesi birkaç bileşenin toplamıdır:

Bölge seçimi çoğunlukla yayılım ve yönlendirmeyi etkiler. Optik fiberdeki ışık, boşluktaki hızının yaklaşık üçte ikisiyle ilerler; bu da herhangi bir yönlendirme sapmasından önce her 100 kilometrelik fiber yolu için yaklaşık 1 milisaniyelik gidiş-dönüş süresine karşılık gelir. Gerçek ağ yolları nadiren düz çizgidir, bu yüzden ölçülen süreler daha yüksektir. Bir kıtadaki cihaz başka bir kıtadaki broker'la konuşuyorsa, her gidiş-dönüşte bu mesafenin bedelini her zaman öder.

Bağlantı kurulumu gidiş-dönüşleri katlar

Gecikme en çok bağlanma anında can yakar. İlk mesaj akmadan önce TLS korumalı bir MQTT istemcisinin bir TCP el sıkışmasına, bir TLS el sıkışmasına ve bir MQTT CONNECT/CONNACK alışverişine ihtiyacı vardır. TLS 1.3 el sıkışması için bir gidiş-dönüş gerekir, TLS 1.2 için genellikle iki. Bu da ilk yayından önce birkaç gidiş-dönüş demektir; derin uykudan uyanan, bağlanan, yayın yapan ve bağlantıyı kesen cihazlarda bu fark edilir. Sürekli bağlı cihazlarda kurulum maliyeti bir kez ödenir ve kararlı durumdaki gidiş-dönüş süresi daha önemlidir.

QoS onay gidiş-dönüşleri ekler

QoS 0 yayını gönder-ve-unut şeklindedir. QoS 1 bir PUBACK bekler, QoS 2 ise dört adımlı bir alışveriş gerektirir. Mesaj abonelere yaklaşık aynı anda ulaşır, ancak yayıncı daha uzun süre bekler; bu da sınırlı in-flight penceresine sahip istemciler için önemlidir. MQTT QoS seviyeleri yazımız bu ödünleşimleri ele alıyor.

Sahalarınızdan MQTT Gecikmesi Nasıl Ölçülür

Genel gecikme haritaları faydalı bir başlangıç noktasıdır, ancak önemli olan kendi sahalarınızdan yaptığınız kendi ölçümlerinizdir. Üç seviyede ölçüm yapın.

Seviye 1: Ağ gidiş-dönüş süresi

Cihaz sahasındaki bir makineden şunu çalıştırın:

# ICMP gidiş-dönüş (bazı ağlar tarafından engellenebilir)
ping -c 20 broker.connectmq.com

# Yolun atlama bazında görünümü, sapmaları fark etmek için faydalı
mtr --report --report-cycles 20 broker.connectmq.com

# MQTT TLS portuna TCP bağlantı süresi
time nc -z -w 5 broker.connectmq.com 8883

nc satırı yalnızca ham bir TCP bağlantısını ölçer; aşağıdaki MQTT seviyesindeki betik daha faydalı TLS ve protokol rakamlarını verir.

Seviye 2: MQTT bağlantısı ve yayın gidiş-dönüşü

paho-mqtt 2.x kullanan bu Python betiği, TLS üzerinden CONNACK'e kadar geçen süreyi ve ardından aynı istemci tarafından yayımlanan ve alınan mesajların gidiş-dönüşünü ölçer. Önemsediğiniz her sahadan çalıştırın.

# mqtt_rtt.py - MQTT bağlantı süresini ve yayın/alma gidiş-dönüşünü ölçer
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)
# Özel bir broker için kimlik bilgilerini ekleyin:
# 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)               # herkese açık broker'da 10 mesaj/sn'nin rahatça altında kal

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")

Aynı istemci hem yayın yapıp hem de aldığı için sonuç, broker üzerinden tam bir gidiş-dönüştür; backend'iniz broker'a yakın konumdaysa bu, cihazdan backend'e gecikme için iyi bir göstergedir. Betik, rastgele bir topic ile herkese açık MQTT test broker'ını kullanır, dolayısıyla hesap gerektirmeden çalışır.

Seviye 3: Kontrolünüzdeki aday bölgeler

Karar vermeden önce konumları karşılaştırmak için her aday bulut bölgesinde küçük bir sanal makine başlatın, TLS ile Mosquitto kurun ve aynı betiği her sahadan her birine karşı çalıştırın. Böylece varsayımlar yerine gerçek rakamlardan oluşan bir matris elde edersiniz.

Ölçümleri Bir Karara Dönüştürmek

Sonuçları, tek ping'ler yerine medyan ve yüksek bir yüzdelik değer kullanarak şuna benzer bir tabloda toplayın:

Ardından şu kuralları uygulayın:

1. Yalnızca cihaz sayısına göre değil, öneme göre ağırlıklandırın. Bir sahadaki bir kontrol döngüsü, başka yerlerdeki yüzlerce dashboard'dan daha önemli olabilir.
2. Backend'inizi dahil edin. Veritabanları ve servisler tek bir bulut bölgesinde çalışıyorsa, onlardan uzaktaki bir broker tüketilen her mesaja gecikme ekler.
3. Yalnızca medyana değil, p90 ve maksimuma da bakın. Etkileşimli her şey için jitter önemlidir.
4. Veri yerleşimi gereksinimlerini kontrol edin. Veri koruma kuralları bölgeyi gecikmeden önce belirleyebilir; bkz. MQTT veri yerleşimi.
5. Bölümlendirmeyi değerlendirin. Sahalar kıtalara yayılmışsa ve düşük gecikme gerekiyorsa, bölge başına ayrı broker'lar tek bir merkezi broker'dan daha iyi olabilir.
6. Gecikmenin nadiren tek etken olduğunu unutmayın. İnsanlar tarafından okunan telemetride maliyet, veri yerleşimi ve operasyonel sadelik çoğu zaman birkaç milisaniyeden daha ağır basar.

ConnectMQ Kurulum Konumu Seçmek

ConnectMQ birkaç kurulum modeli sunar ve konum her birinde farklı işler:

• Serverless (Free ve Paid): broker'ınız ConnectMQ'nun paylaşımlı kümesinde çalışır. Gidiş-dönüş süresinin ihtiyaçlarınızı karşılayıp karşılamadığını görmek için ölçüm betiğini sahalarınızdan ona karşı çalıştırın.
• Dedicated: iş yükünüz için izole bir küme. Konum seçeneklerini ekiple görüşün ve ölçüm tablonuzu getirin.
• BYOC: broker kendi bulut hesabınızda çalışır, dolayısıyla diğer sistemlerinizin zaten bulunduğu bölgede konumlanabilir. Planlama sırasında desteklenen sağlayıcıları ve bölgeleri ekiple teyit edin; BYOC MQTT broker rehberimiz bu modeli anlatıyor.
• Self Managed Enterprise: kendi altyapınızı nerede çalıştırıyorsanız oraya yerleştirirsiniz.

Çoğu telemetri ve izleme iş yükü için cihazlarla aynı geniş coğrafyada iyi konumlanmış bir broker yeterlidir. Sıkı kontrol döngülerini uçta yerel tutun ve bulut broker'ı denetim, raporlama ve entegrasyon için kullanın. Gerçek zamanlı dijital ikiz gecikmesi yazımız bu ayrımı daha ayrıntılı ele alıyor.

Yaygın Gecikme Tuzakları

• Ofisten bir kez ölçmek. Gerçek cihaz ağlarından, özellikle hücresel sahalardan ölçün.
• Wi-Fi'ın suçunu broker'a atmak. Önce ağ testlerini çalıştırın; erişim ağları çoğu zaman mesafeden daha fazla gecikmeye katkıda bulunur.
• Her mesaj için yeniden bağlanmak. Derin uyku cihazları her uyanışta birkaç gidiş-dönüş öder; güç izin verdiğinde oturumları açık tutun.
• Aboneleri broker'dan uzağa yerleştirmek. Başka bir bölgedeki backend, her mesajın kat ettiği mesafeyi ikiye katlar.
• DNS'i göz ardı etmek. Yavaş çözümleyiciler her yeni bağlantıya gecikme ekler; sonuçları ağ geçitlerinde önbelleğe alın.

Gecikmenizi ConnectMQ'da Ölçün

ConnectMQ, Serverless, Dedicated ve BYOC kurulum seçeneklerine sahip barındırılan bir MQTT broker'dır; böylece konumu sahalarınıza ve sistemlerinize göre eşleştirebilirsiniz. app.connectmq.com adresinde kredi kartı gerekmeden ücretsiz bir Serverless broker oluşturun, betiği sahalarınızdan çalıştırın ve sonuçları üretim kurulumunuzu seçmek için kullanın. Bulut MQTT broker rehberi barındırma kararının geri kalanını, bir MQTT broker nasıl ölçeklendirilir yazısı ise kapasiteyi ele alıyor.

Sık Sorulan Sorular

Bölge seçimi MQTT gecikmesini ne kadar etkiler?

Mesafe, her 100 kilometrelik fiber için yaklaşık 1 milisaniyelik bir minimum gidiş-dönüş süresi belirler ve gerçek rotalar buna ek yapar. Başka bir kıtadaki cihazlar için bölge seçimi genellikle gecikmenin ağ kısmına hâkimdir.

MQTT broker gecikmesini ölçmenin en iyi yolu nedir?

Cihaz sahasından bağlantı, TLS ve yayından almaya kadar olan gidiş-dönüşü zamanlayan MQTT seviyesinde bir test çalıştırın ve çok sayıda örnek üzerinden medyan ve yüksek yüzdelik değerleri toplayın.

TLS MQTT'yi yavaşlatır mı?

TLS bağlanma anında gidiş-dönüşler ekler, ancak sonrasında mesaj başına maliyeti çok düşüktür. El sıkışmanın bir kez ödenmesi için mümkün olduğunda bağlantıları açık tutun.

ConnectMQ broker'ımın nerede çalışacağını seçebilir miyim?

BYOC ile broker kendi bulut hesabınızda çalışır, dolayısıyla bölgeyi ekibin desteklediği seçenekler içinden siz seçersiniz. Dedicated kurulumlar için konumu ekiple görüşün.