Bir MQTT broker kaç bağlantıyı kaldırabilir? Dürüst cevap "duruma göre değişir"; ancak bu, ölçebileceğiniz ve planlayabileceğiniz kısa ve somut bir kaynak listesine bağlıdır. Bu yazı eşzamanlı MQTT bağlantılarını neyin sınırladığını, yayımlanan sayıların neden nadiren sizin iş yükünüzle örtüştüğünü, kapasiteyi kendiniz nasıl test edebileceğinizi ve yönetilen sağlayıcıların tüm bunları nasıl plan limitlerine dönüştürdüğünü açıklıyor.
Neden Tek Bir Sayı Yok
Üretici pazarlama materyallerinde ve konferans sunumlarında etkileyici bağlantı sayılarıyla karşılaşırsınız. Bunlar genellikle gerçektir, ancak belirli koşullar altında ölçülmüştür: boşta bekleyen istemciler, TLS olmadan ya da oturum yeniden kullanımıyla, çok küçük veya hiç olmayan payload'lar, cömert donanım ve özenle ayarlanmış çekirdekler. Bunlardan herhangi birini değiştirdiğinizde sayı da değişir.
Sizin için önemli olan, bir broker'ın laboratuvarda ulaşabileceği maksimum değil; belirli bir kurulumun sizin keepalive, TLS, abonelik ve mesaj desenlerinize sahip sizin istemcilerinizden kaçına pay bırakarak hizmet verebileceğidir. Bunun için darboğazları anlamak gerekir.
Eşzamanlı MQTT Bağlantılarını Ne Sınırlar
| Kaynak | Her bağlantı neden kullanır | Durumu ne kötüleştirir |
|---|---|---|
| Bellek | Soket tamponları, TLS durumu, oturum nesnesi, abonelikler, aktarımdaki mesajlar | Büyük tamponlar, istemci başına çok sayıda abonelik, kuyruktaki QoS 1/2 mesajları |
| Dosya tanımlayıcıları | Unix benzeri sistemlerde her TCP soketi açık bir dosyadır | Düşük varsayılan ulimit değerleri, loglar ve kalıcılık için ek tanımlayıcılar |
| TLS için CPU | El sıkışmalar açık anahtarlı kriptografi içerir | Yeniden bağlanma fırtınaları, oturum yeniden kullanımının olmaması, büyük anahtar boyutları |
| Keepalive için CPU | Her aralıkta her istemci için PINGREQ ve PINGRESP | Büyük filolarda çok kısa keepalive aralıkları |
| Ağ ve çekirdek | Bağlantı tabloları, kabul kuyrukları, yük dengeleyici limitleri | Küçük accept backlog, conntrack tabloları, IP başına limitler |
| Oturum durumu | Kalıcı oturumlar bağlantı kopmalarından sonra da yaşar | Hiç geri dönmeyen istemciler için uzun oturum sona erme süreleri |
Bellek
Sessiz cihazlardan oluşan büyük filolarda ilk katı sınır genellikle bellektir. Her bağlantı çekirdek soket tamponlarını, broker'ın istemci başına kendi yapılarını, TLS oturum durumunu ve kuyruktaki mesajları taşır. Abonelikler, özellikle çok sayıda wildcard filtresiyle, daha fazla yük ekler. Kalıcı oturumla bağlantısı kopan istemciler, oturum sona erene kadar bellek kullanmaya devam eder.
Dosya tanımlayıcıları
Linux'ta her soket bir dosya tanımlayıcısı tüketir. Birçok dağıtımda varsayılan soft limit bir broker için fazlasıyla düşüktür; insanlar ilk kez kendi sunucularında barındırdığında "too many open files" hatasının en sık görülen hatalardan biri olmasının nedeni budur. Limiti inceleyip yükseltebilirsiniz:
# Kabuk için mevcut limitler
ulimit -n
ulimit -Hn
# Çalışan bir broker sürecinin limitleri (PID'i değiştirin)
cat /proc/PID/limits | grep "open files"
# Broker'ın açık soketlerini say
ls /proc/PID/fd | wc -l
Bir systemd servisi için limiti bir drop-in dosyasında yükseltin:
# /etc/systemd/system/mosquitto.service.d/limits.conf
[Service]
LimitNOFILE=200000
Ardından sudo systemctl daemon-reload && sudo systemctl restart mosquitto komutunu çalıştırın.
TLS
TLS her üretim bağlantısını korur ve bunun bir maliyeti vardır. Küçük MQTT mesajlarının sürekli şifrelenmesi ucuzdur, ancak el sıkışma görece pahalıdır. Bu durum en çok, örneğin tesis genelindeki bir elektrik kesintisinden veya broker yeniden başlatmasından sonra, çok sayıda istemci aynı anda bağlandığında önem kazanır. Kararlı durumdaki filosunu rahatça taşıyan bir broker, hepsini aynı dakika içinde kabul etmekte yine de zorlanabilir. İstemcilerde rastgele sapmalı (jitter) yeniden bağlanma gecikmeleri en iyi savunmadır.
Keepalive
Her istemci, keepalive aralığı içinde gönderecek başka bir şeyi yoksa bir PINGREQ gönderir. Büyük bir filoda çok kısa keepalive değerleri sürekli bir arka plan yükü oluşturur. 30 ile 60 saniye civarında bir keepalive, hızlı hata tespiti ile ek yük arasında yaygın bir dengedir; pille çalışan cihazlar genellikle daha uzun değerler kullanır.
Ağ yolu
Yük dengeleyiciler, NAT ağ geçitleri ve güvenlik duvarları bağlantı başına durum tutar ve kendi limitlerine sahiptir. Kendi barındırdığınız kurulumlarda, broker'ın önüne durum bilgili (stateful) bir güvenlik duvarı koyuyorsanız çekirdek accept backlog değerini (net.core.somaxconn) ve bağlantı izleme tablosu boyutlarını kontrol edin.
Bağlantı Kapasitesini Kendiniz Nasıl Test Edersiniz
Kendi broker'ınızı çalıştırıyorsanız tahmin etmek yerine ölçün. Aşağıdaki betik, tek bir makineden, yerel bir Mosquitto örneği gibi kontrolünüzdeki bir broker'a çok sayıda boşta bağlantı açar. Bağlantı testlerini paylaşımlı veya herkese açık bir broker'a karşı çalıştırmayın; flood korumasına takılır ve diğer kullanıcıları etkilersiniz.
# conn_test.py - KENDİ test broker'ınıza N adet boşta MQTT bağlantısı açar
import sys
import time
import paho.mqtt.client as mqtt
HOST = sys.argv[1] if len(sys.argv) > 1 else "localhost"
COUNT = int(sys.argv[2]) if len(sys.argv) > 2 else 500
connected = 0
def on_connect(client, userdata, flags, reason_code, properties):
global connected
if not reason_code.is_failure:
connected += 1
clients = []
start = time.time()
for i in range(COUNT):
c = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"conn-test-{i}")
c.on_connect = on_connect
try:
c.connect(HOST, 1883, keepalive=60)
c.loop_start()
clients.append(c)
except OSError as exc:
print(f"failed at {i}: {exc}")
break
if i % 100 == 0:
time.sleep(0.5) # artışı kademelendir
time.sleep(5)
print(f"{connected}/{COUNT} connected in {time.time() - start:.1f}s")
input("Press Enter to disconnect all clients...")
for c in clients:
c.disconnect()
c.loop_stop()
Broker'ın bellek ve CPU kullanımını top veya htop ile izlerken betiği python conn_test.py localhost 2000 ile çalıştırın. Her paho istemcisinin kendi iş parçacığını başlattığını unutmayın; dolayısıyla bir noktada test makinesinin kendisi darboğaz hâline gelir. Olay döngüsü kullanan özel yük test araçları daha iyi ölçeklenir. Test makinesinde de ulimit -n değerini yükseltin. Testi TLS etkinken ve gerçekçi aboneliklerle tekrarlayın; çünkü boşta, düz TCP ile elde edilen sayılar göreceğiniz en iyimser sonuçlardır.
Yönetilen Broker'lar Bağlantı Limitlerini Nasıl Belirler
Yönetilen sağlayıcılar da aynı kısıtlarla karşı karşıyadır; ancak siz çekirdek ayarlamak zorunda kalmayasınız diye bunları plan kotalarına dönüştürürler. Paylaşımlı bir kümede kota, ayrıca her kiracıyı diğer tüm kiracılardan korur.
ConnectMQ, plana göre şu bağlantı limitlerini yayımlar:
| Plan | Bağlantı limiti | Diğer önemli limitler |
|---|---|---|
| Herkese açık test broker'ı | Adil kullanım, istemci başına limitler | 64 KB mesaj, 10 mesaj/sn, istemci başına 10 abonelik |
| Serverless (Free) | 25'e kadar | QoS 1'e kadar, 256 KB mesaj |
| Serverless (Paid) | 1.000'e kadar | QoS 2, 1 MB mesaj, shared subscription |
| Dedicated | İzole bir kümede iş yükünüze göre boyutlandırılır | Ekiple görüşülür |
| BYOC | Kendi bulut hesabınızda iş yükünüze göre boyutlandırılır | Ekiple görüşülür |
| Self Managed Enterprise | Siz işletir ve boyutlandırırsınız | Ekiple görüşülür |
Dedicated ve BYOC için doğru sayı, bu yazıdaki etkenlere bağlıdır: keepalive değeriniz, TLS kullanımınız, mesaj hızınız ve oturum davranışınız. Kurulumu kapsamlandırırken tek bir manşet rakam istemek yerine bu ayrıntıları paylaşın. Bir kotayı aşarsanız MQTT 5 istemcileri 0x97 quota exceeded reason code'unu alır; MQTT broker bağlantı kotaları rehberimiz bunun nasıl ele alınacağını açıklıyor.
Bağlantıları Doğru Saymak
Ekipler sıklıkla eksik sayar. Tahmin yaparken bu kontrol listesini kullanın:
- Kendi MQTT oturumuna sahip her cihaz veya ağ geçidi.
- Her backend servis örneği: veritabanı yazıcıları, uyarı sistemleri, API'ler.
- Node-RED, Telegraf veya Home Assistant gibi her entegrasyon aracı.
- WebSocket üzerinden MQTT istemcisi çalıştıran her dashboard veya tarayıcı sekmesi.
- Geliştirici araçları: masaüstü gezginler, CLI oturumları, test betikleri.
- Dağıtımlar sırasında eski ve yeni servis örneklerinin birlikte çalıştığı geçici örtüşme.
- Önümüzdeki altı ila on iki ay için büyüme payı.
Ağ geçitleri hesabı değiştirir. Elli PLC etiketini toplayan bir endüstriyel ağ geçidi ya da düzinelerce sensörü ileten bir BLE ağ geçidi elli değil, tek bir MQTT bağlantısı kullanır. Bir plan limitine yakınsanız, uçta toplama yapmak çoğu zaman plan yükseltmekten daha ucuzdur.
Pratik Çıkarımlar
- Bağlantı kapasitesi sabit bir sayı değil; bellek, dosya tanımlayıcıları, TLS maliyeti, keepalive trafiği ve oturum durumunun bir fonksiyonudur.
- Kararlı durum kapasitesi ile yeniden bağlanma fırtınası kapasitesi farklıdır; istemcileri jitter'lı geri çekilme (backoff) ile tasarlayın.
- Kendi iş yükünüzü, kontrolünüzdeki donanımda ve TLS açıkken test edin.
- Yönetilen bir serviste önemli olan sayı plan kotalarıdır ve yalnızca cihazları değil, her istemciyi saymalısınız.
Bağlantılar yerine verim için saniyedeki MQTT mesaj sayısını tahmin etme yazısını, büyüme stratejileri için bir MQTT broker nasıl ölçeklendirilir yazısını okuyun. Bulut MQTT broker rehberi tüm bunları barındırma seçenekleri bağlamına oturtuyor.
ConnectMQ ile Başlayın
ConnectMQ, plan başına net bağlantı limitleri sunan tam yönetilen bir MQTT servisidir; böylece sunucu ayarlamadan kapasite planlayabilirsiniz. app.connectmq.com adresinde kredi kartı gerekmeden ücretsiz bir Serverless broker oluşturun ve filonuz büyüdükçe ücretli Serverless, Dedicated veya BYOC'ye geçin.
Sık Sorulan Sorular
Bir MQTT broker tek bir sunucuda kaç bağlantıyı kaldırabilir?
Bu; belleğe, dosya tanımlayıcı limitlerine, TLS kullanımına, keepalive aralıklarına ve oturum durumuna bağlıdır. Manşet bir sayıya güvenmek yerine kendi istemci davranışınızla ve TLS etkinken ölçüm yapın.
TLS bir broker'ın kaldırabileceği MQTT bağlantı sayısını azaltır mı?
TLS bağlantı başına bellek ekler ve el sıkışmaları CPU yoğun hâle getirir; bu en çok yeniden bağlanma fırtınalarında önem taşır. Küçük mesajlar için kararlı durumdaki şifreli trafik görece ucuzdur.
Boşta bekleyen MQTT istemcileri de broker kaynaklarını kullanır mı?
Evet. Boşta bekleyen bir istemci yine de bir soket, oturumu ve abonelikleri için bellek tutar ve keepalive ping'leri gönderir; dolayısıyla sessiz filolar da kapasite tüketir.
ConnectMQ ücretsiz planı kaç bağlantıya izin verir?
Serverless (Free) planı 25'e kadar eşzamanlı bağlantıya, ücretli Serverless planı ise 1.000'e kadar bağlantıya izin verir. Dedicated ve BYOC kurulumları iş yükünüze göre boyutlandırılır.



