Saniyede MQTT Mesaj Sayısı: Verim Nasıl Tahmin Edilir ve Ölçülür

Saniyedeki MQTT mesaj sayısını tahmin etmek, bir broker planı seçmeden önce yapabileceğiniz en faydalı boyutlandırma çalışmasıdır ve bir saatten kısa sürer. Bu rehber, filonuz için gelen ve giden mesaj hızlarını nasıl hesaplayacağınızı, tepe değerleri ve protokol ek yükünü nasıl hesaba katacağınızı, gerçek trafiği kısa bir betikle nasıl ölçeceğinizi ve rakamları bir plan kararına nasıl dönüştüreceğinizi gösteriyor.

Gelen, Giden ve İkisinin de Neden Önemli Olduğu

Bir broker iki mesaj akışını yönetir:

• Gelen (inbound): istemcilerin broker'a yayımladığı mesajlar.
• Giden (outbound): broker'ın eşleşen abonelere teslim ettiği kopyalar.

Her mesajın tam olarak bir abonesi varsa ikisi eşittir. Gerçek sistemlerde nadiren böyledir. Bir dashboard, bir historian ve bir uyarı servisi tarafından okunan bir telemetri mesajı üç giden teslimat üretir. Tek bir cihaza gönderilen bir komut bir teslimat üretir. # üzerindeki bir hata ayıklama aracı gibi wildcard aboneler her şeyi alır. Giden sayı çoğu zaman daha büyüktür, bu yüzden her zaman ikisini birden tahmin edin.

Temel Formüller

Yalnızca üç formüle ihtiyacınız var:

1. Gelen hız (mesaj/sn) = yayıncı sayısı x yayıncı başına saniyedeki mesaj sayısı
2. Giden hız (mesaj/sn) = her topic'teki gelen hız x eşleşen abone sayısı, tüm topic'ler üzerinden toplanır
3. Bant genişliği (bayt/sn) = (gelen + giden) x ortalama mesaj boyutu, artı protokol ve TLS ek yükü

Buradaki mesaj boyutu, MQTT payload'ı artı topic dizesi ve birkaç baytlık sabit başlık anlamına gelir. Küçük telemetri verilerinde topic, payload kadar büyük olabilir; MQTT 5 topic alias'larının var olmasının bir nedeni de budur.

Mesajlar yerine paketler üzerinden düşünürken QoS'u unutmayın. QoS 0 her teslimat için bir paket gönderir. QoS 1 her yönde her yayın için bir PUBACK ekler. QoS 2 dört paketlik bir alışveriş kullanır. Mesaj sayısı değişmez, ancak paket sayısı ve broker'ın yaptığı iş değişir.

Örnek Bir Hesaplama

Üç tür yayıncıya sahip varsayımsal bir tesis düşünün. Bu rakamlar ölçüm değil, açıklama amaçlıdır.

Böyle bir tablodan neredeyse her seferinde üç gözlem çıkar:

• On beş hızlı ağ geçidi trafiğin çoğunu üretirken 120 yavaş sensör neredeyse hiç fark edilmez.
• Fan-out nedeniyle giden trafik, gelenin neredeyse üç katıdır.
• Bağlantı sayısı (270 istemci artı backend aboneleri), mesaj hızı bir sorun hâline gelmeden çok önce ilk ulaşacağınız limit olabilir.

Ortalamalara Değil, Tepe Değerlere Göre Planlama

Ortalamalar sorun yaratan anları gizler. Şunlar için açık paylar ekleyin:

• Yeniden bağlanma selleri. Bir kesintiden sonra cihazlar birlikte yeniden bağlanır ve birçoğu tamponlanmış okumaları aynı anda boşaltır.
• Senkronize zamanlayıcılar. Aynı anda açılan ve her 60 saniyede bir yayın yapan cihazlar aynı saniyede yayın yapar. İlk yayına rastgele bir sapma (jitter) ekleyin.
• Olay patlamaları. Alarmlar çoğu zaman zincirleme ilerler: tek bir arıza düzinelerce ilişkili uyarıyı tetikler.
• Vardiya veya program değişiklikleri. Birlikte başlayan üretim hatları trafikte basamaklı değişiklikler yaratır.
• Hata ayıklama oturumları. Bir masaüstü aracında # konusuna abone olan biri, tüm trafiğin tam bir kopyasını ekler.

Basit bir pratik kural, ortalamanızın birkaç katı bir tepe değere göre boyutlandırmak ve istemcilerin patlamalarını hız sınırlama ve jitter ile yumuşattığını doğrulamaktır.

Gerçek Mesaj Hızlarını Ölçmek

Tahminler bir başlangıç noktasıdır; ölçüm ise sizi gerçekçi tutar. Aşağıdaki betik bir topic filtresine abone olur ve her beş saniyede bir saniyedeki mesaj ve bayt sayısını yazdırır. Üretim kimlik bilgileriyle kendi broker'ınıza yönlendirin veya benzersiz bir topic önekiyle herkese açık MQTT test broker'ında deneyin.

# rate_meter.py - bir topic filtresinde saniyedeki MQTT mesaj sayısını ölçer
import sys
import threading
import time

import paho.mqtt.client as mqtt

HOST = "broker.connectmq.com"
FILTER = sys.argv[1] if len(sys.argv) > 1 else "connectmq/demo/r8m2/#"
WINDOW = 5

lock = threading.Lock()
count = 0
nbytes = 0
per_topic = {}

def on_connect(client, userdata, flags, reason_code, properties):
    print("connected:", reason_code, "- measuring", FILTER)
    client.subscribe(FILTER, qos=0)

def on_message(client, userdata, msg):
    global count, nbytes
    with lock:
        count += 1
        nbytes += len(msg.payload) + len(msg.topic)
        per_topic[msg.topic] = per_topic.get(msg.topic, 0) + 1

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                     client_id="rate-meter-r8m2", protocol=mqtt.MQTTv5)
# Özel broker'ınız için bunların yorumunu kaldırın ve 8883 portunu kullanın:
# client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
# client.tls_set()
client.on_connect = on_connect
client.on_message = on_message
client.connect(HOST, 1883)
client.loop_start()

while True:
    time.sleep(WINDOW)
    with lock:
        msgs, size, top = count, nbytes, sorted(per_topic.items(), key=lambda kv: -kv[1])[:3]
        count = nbytes = 0
        per_topic.clear()
    print(f"{msgs / WINDOW:8.1f} msg/s  {size / WINDOW / 1024:8.2f} KB/s  top: {top}")

Başka bir terminalde test trafiği üretmek için:

for i in $(seq 1 200); do
  mosquitto_pub -h broker.connectmq.com -p 1883 -i rate-pub-r8m2 \
    -t "connectmq/demo/r8m2/sensor/$((i % 5))" -m "{\"v\":$i}"
  sleep 0.2
done

Hız ayarı önemlidir: herkese açık broker istemci başına saniyede 10 mesaja izin verir, bu yüzden test yayıncılarını bunun altında tutun. Bir üretim broker'ını ölçerken ölçeri kendi kimlik bilgilerine sahip ayrı bir istemci olarak çalıştırın ve ölçümü gece değil, yoğun bir dönemde yapın.

Verimi Bir Broker Planına Eşlemek

Rakamlarınız olduğunda bunları plan limitleriyle eşleştirin. ConnectMQ'da kontrol etmeniz gereken plan limitleri şunlardır:

Tabloyu tahmininizle karşılaştırarak nasıl okuyacağınız:

1. Önce bağlantılar. Yayıncıları, aboneleri, dashboard'ları ve araçları toplayın. Bu sayı genellikle Free ile Paid Serverless arasındaki seçimi belirler.
2. İkinci olarak en büyük mesaj. Birikmiş bir toplu gönderim dahil herhangi bir mesaj 256 KB'yi aşıyorsa ücretli plana ya da daha küçük gruplara ihtiyacınız vardır.
3. Üçüncü olarak QoS. Herhangi bir akış tam olarak bir kez teslimat gerektiriyorsa QoS 2'ye ihtiyacınız vardır.
4. Dördüncü olarak tüketici ölçeklemesi. Tek bir backend abonesi giden hızınıza yetişemiyorsa, yükü örnekler arasında bölmek için shared subscription'a ihtiyacınız vardır.
5. En son izolasyon. Veriminiz yüksek ve sürekliyse ya da diğer kiracıların etkinliğinin sizinkini etkilemesini kabul edemiyorsanız Dedicated veya BYOC'yi görüşün ve gelen, giden ve tepe rakamlarınızı ekiple paylaşın.

Limitlere ulaşıldığında kotaların nasıl davrandığı için MQTT broker bağlantı kotaları yazısını okuyun. Bir kurulumu büyütmenin daha geniş resmi için bir MQTT broker nasıl ölçeklendirilir ve bir MQTT broker kaç bağlantıyı kaldırabilir yazılarına göz atın.

Mesaj Hızını Azaltmanın Yolları

Tahmininiz istediğinizden yüksekse, bu teknikler bilgi kaybetmeden trafiği azaltır:

• İstisna durumunda raporlayın. Sabit bir zamanlayıcı yerine, bir değer ölü bandın (deadband) ötesinde değiştiğinde yayınlayın.
• Örnekleri gruplayın. On mesaj yerine on okuma içeren tek bir mesaj gönderin.
• Uçta örnekleme hızını düşürün. Tüketiciler ham veriye ihtiyaç duymuyorsa yüksek frekanslı ham örnekler yerine bir saniyelik ortalamalar yayınlayın.
• Abonelikleri daraltın. Giden trafiği katlayan gereksiz # abonelerini kaldırın.
• Kompakt payload'lar kullanın. Daha kısa JSON anahtarları veya Protobuf gibi ikili kodlamalar mesaj başına bayt sayısını azaltır.
• Topic alias'ları kullanın. MQTT 5'te alias'lar, tekrar eden uzun topic dizelerini küçük bir tamsayıya indirir.

ConnectMQ ile Başlayın

ConnectMQ, plan başına net limitler, canlı bir topic gezgini ve trafiği akarken izleyebileceğiniz bir dashboard sunan yönetilen bir MQTT broker'dır. app.connectmq.com adresinde kredi kartı gerekmeden ücretsiz bir Serverless broker oluşturun, hız ölçeri ona karşı çalıştırın ve rakamlarınızın işaret ettiği planı seçin. Barındırma seçeneklerinin tamamı için bulut MQTT broker rehberine bakın.

Sık Sorulan Sorular

Saniyedeki MQTT mesaj sayısını nasıl hesaplarım?

Gelen hızı bulmak için yayıncı sayısını her birinin yayın sıklığıyla çarpın; ardından giden hızı bulmak için her topic'in gelen hızını abone sayısıyla çarpın. Tepe değerler için pay ekleyin.

Giden trafik neden gelenden fazladır?

Yayımlanan her mesaj eşleşen her aboneye teslim edilir; dolayısıyla üç servis tarafından okunan bir mesaj giden tarafta üç kez sayılır. Wildcard aboneler bunu daha da artırır.

QoS saniyedeki mesaj sayısını etkiler mi?

QoS gönderdiğiniz mesaj sayısını değiştirmez, ancak QoS 1 ve 2 her mesaj için onay paketleri ve ek broker işi ekler. Bir sonraki örneğin öncekinin yerini aldığı yüksek hızlı telemetri için QoS 0 kullanın.

ConnectMQ herkese açık broker'ı hangi mesaj hızına izin verir?

Herkese açık test broker'ı istemci başına saniyede 10 mesaja ve mesaj başına 64 KB'ye izin verir. Özel planlar bağlantı sayısı, mesaj boyutu ve QoS limitleriyle tanımlanır; bunları tahmininizle karşılaştırın.