MQTT Broker Yük Testi: Throughput ve Gecikmeyi Ölçün

Tek bir test istemcisiyle sorunsuz çalışan bir broker, bin cihazla çökebilir. MQTT broker yük testi, üç soruyu production'dan önce yanıtlar: broker kaç eşzamanlı bağlantı kabul ediyor, saniyede kaç mesaj yönlendirebiliyor ve yoğunken subscriber'larınız ne kadar gecikme görüyor.

Bu rehber; bir benchmark'ı nasıl planlayacağınızı, iki açık kaynak araç ve bir Python betiğiyle nasıl çalıştıracağınızı ve sayıları kendinizi kandırmadan nasıl okuyacağınızı gösteriyor.

Neyi ölçmeli

Benchmark'ı her zaman cihazlarınızın kullandığı aynı QoS, payload boyutu ve topic yapısıyla yapın. Tek bir topic'e 10 baytlık QoS 0 mesajları gönderen bir test, 50.000 topic'e dağılmış 2 KB'lık QoS 1 telemetrisi hakkında hiçbir şey söylemez. Her seviyenin paket sayısını nasıl değiştirdiğini görmek için MQTT QoS seviyeleri yazısına bakın.

Doğru hedefi seçin

Ağır bir benchmark'ı asla paylaşımlı, herkese açık bir sandbox'a karşı çalıştırmayın: sayılar anlamsız olur (diğer tüm kullanıcılarla yarışırsınız) ve operatörler sizi kısıtlar veya engeller. Orada bir smoke test yapın, ardından yükü kontrol ettiğiniz bir instance'a yönlendirin.

Aşağıdaki örneklerde broker.connectmq.com kullanıyoruz; host, port ve kimlik bilgilerini kendi instance'ınızınkilerle değiştirin.

1. emqtt-bench

emqtt-bench, tek bir makineden on binlerce bağlantı açabilen Erlang tabanlı bir araçtır. En kolay çalıştırma yolu Docker'dır:

docker run --rm -it emqx/emqtt-bench conn \
  -h broker.connectmq.com -p 1883 \
  -c 2000 -R 200 \
  -u "$MQTT_USER" -P "$MQTT_PASS"

Ardından aynı anda çalışan bir subscriber grubu ve bir publisher grubuyla throughput'u ölçün:

docker run --rm -it emqx/emqtt-bench sub \
  -h broker.connectmq.com -p 1883 \
  -c 100 -t 'bench/%i/#' -q 1

docker run --rm -it emqx/emqtt-bench pub \
  -h broker.connectmq.com -p 1883 \
  -c 100 -I 10 -t 'bench/%i/data' -s 256 -q 1

%i istemci indeksine genişler; böylece her publisher'ın kendi topic'i ve kendi subscriber'ı olur: gerçekçi, bire bir bir telemetri deseni. 100 publisher × 100 msg/s, saniyede 10.000 mesaj hedefi demektir. emqtt-bench her saniye gönderim ve alım hızlarını yazdırır; alım hızı gönderim hızının gerisinde kalıyorsa darboğaz broker'dır (ya da ağınız).

2. mqtt-benchmark (Go)

Tek bir binary tercih ediyorsanız mqtt-benchmark sabit sayıda mesaj yayınlar ve throughput ile gecikme istatistiklerini raporlar:

go install github.com/krylovsk/mqtt-benchmark@latest

mqtt-benchmark \
  --broker tcp://broker.connectmq.com:1883 \
  --clients 50 --count 1000 --size 512 --qos 1 \
  --topic bench/go --format text

Sondaki özet; istemci başına saniyedeki mesaj sayısını, toplam hızı ve publish sürelerinin ortalamasını / standart sapmasını içerir. İki broker'ı veya iki yapılandırmayı karşılaştırmanın hızlı bir yoludur.

3. Güvenebileceğiniz bir gecikme betiği

Throughput araçları mesajların ne kadar hızlı girdiğini ölçer. Kullanıcılar ise ne kadar hızlı çıktığını hisseder. Bu Python betiği (paho-mqtt 2.x) her payload'a gönderim zamanını gömer ve subscriber tarafında uçtan uca yüzdelikleri hesaplar:

import json, statistics, time, uuid
import paho.mqtt.client as mqtt

HOST, PORT = "broker.connectmq.com", 1883
TOPIC = f"bench/{uuid.uuid4().hex[:8]}/latency"
N, RATE = 2000, 200          # mesaj sayısı, saniyedeki mesaj
samples = []

def on_message(client, userdata, msg):
    sent = json.loads(msg.payload)["t"]
    samples.append((time.perf_counter() - sent) * 1000)

sub = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2)
sub.on_message = on_message
sub.connect(HOST, PORT)
sub.subscribe(TOPIC, qos=1)
sub.loop_start()

pub = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2)
pub.connect(HOST, PORT)
pub.loop_start()
time.sleep(1)                # aboneliğin oturmasını bekle

for i in range(N):
    pub.publish(TOPIC, json.dumps({"i": i, "t": time.perf_counter()}), qos=1)
    time.sleep(1 / RATE)

time.sleep(3)
samples.sort()
p = lambda q: samples[int(len(samples) * q) - 1]
print(f"received {len(samples)}/{N}")
print(f"p50 {p(0.50):.1f} ms  p95 {p(0.95):.1f} ms  p99 {p(0.99):.1f} ms  max {samples[-1]:.1f} ms")
print(f"mean {statistics.mean(samples):.1f} ms")

Publisher ve subscriber aynı süreçte çalıştığı için aynı saati paylaşırlar: sonuçta NTP kayması olmaz. Betiği bir kez broker boştayken, bir kez de emqtt-bench broker'ı yüklenirken çalıştırın: aradaki fark, cihazlarınızın tepe anında göreceği gecikmedir.

Sonuçları okumak

• QoS 0'da alınan < gönderilen ise broker veya istemci baskı altında mesaj düşürmüştür. Bunun bir teslimat mı yoksa kapasite sorunu mu olduğunu görmek için QoS 1 ile tekrar deneyin.
• p99'un p50'nin çok üzerinde olması; garbage collection duraklamalarına, diske dayalı kalıcılığa veya doymuş bir ağ bağlantısına işaret eder. Broker CPU'sunu ve yük üretecinin CPU'sunu kontrol edin; sınırına dayanmış bir benchmark makinesi en yaygın yanıltıcı sonuçtur.
• Bağlantı testi yuvarlak bir sayıda takılıyorsa (1.024, 4.096, 65.535) broker'da değil, yük üretecinde bir file descriptor veya ephemeral port limitine ulaşmışsınızdır. ulimit -n değerini artırın ya da yükü birkaç makineye veya kaynak IP'ye dağıtın.
• Test sırasında bağlantı kopmaları: keep alive timeout'larına veya broker'ın istemci başına inflight / kuyruk limitlerine bakın. MQTT keep alive ve bağlantı hataları yazılarına göz atın.

Tekrarlanabilir bir yük testi kontrol listesi

1. Önce online MQTT istemcisi veya mosquitto_pub / mosquitto_sub ile bağlantıyı smoke test edin.
2. Senaryoyu sabitleyin: istemci sayısı, QoS, payload boyutu, topic yapısı, retained olup olmadığı.
3. Yükü kademeli artırın (beklenen tepenin %10, %50, %100, %150'si) ve her adımı birkaç dakika koruyun.
4. İstemci tarafı sayıların yanına broker CPU, bellek ve bağlantı sayısını da kaydedin.
5. Testi iki kez tekrarlayın; yalnızca tekrarlanabilen sonuçlara güvenin.
6. Her broker güncellemesinden veya yapılandırma değişikliğinden sonra testi yeniden çalıştırın.

Önce broker'ı tarayıcınızda smoke test edin

Yük testi, "benim laptopumda çalışıyor" cümlesini kapasite planlayabileceğiniz bir sayıya dönüştürür. Küçük başlayın, gecikmeyi kullanıcılarınızın bulunduğu yerde ölçün ve betikleri deponuzda tutun; böylece bir sonraki benchmark günler yerine dakikalar sürer.

Sıkça sorulan sorular