Hallo Freunde
Das der eingebaute MQTT Broker diverse Limits hat wurde ja schon diskutiert und ist absolut verständlich.
Aber wo liegt die ungefähr ?
Könnt ihr uns irgendeine Zahl geben wieviel Last man dem MQTT Server so zumuten kann.
10/100/1000 Topics pro Sekunde publishen ?
10/100/1000 Topics pro Sekunde abfragen ?
Inwieweit trägt zur Last bei ob Topics abonniert sind oder nicht ?
Inwieweit trägt die Größe eines Topics zur Last bei ?
Benötigt abfragen oder publishen mehr Resourcen ?
Inwieweit drücken diverse Authentifizierungen auf die Performance ?
Insbesondere mit selbstgebauten Nodes hat man ja viele Parameter in der Hand. u.a. auch die Entscheidung ob eine Applikation überhaupt dafür geeignet ist über den MQTT zu laufen. Oder ob man verschiedene Komplexitäten eher am Node oder am ISP Server laufen läßt (was natürlich mehr oder weniger MQTT Traffic verursacht).
Mir ist absolut klar das dies keine absolute Werte geben kann und wohl noch weitere Faktoren mitspielen. Aber habt ihr irgendein Bauchgefühl für uns. Eine Guidance ?
Hallo Bernhard,
ich habe mich auch schon gefragt, wo es da ein Limit gibt und wie man das überwachen kann.
Wäre interessant, mal die Stressfaktoren zu messen, auch wenn es hier sicherlich 1000 verschiedene Einflüsse gibt.
Ich hatte am Anfang nur einen internen MQTT Server am laufen.
Das hat mit den Modulen (Tasmota) die ich so hatte gut funktioniert.
Dann sind da die Shelly Module auf den Markt gekommen, und ich hatte mir einige besorgt.
Danach hatte ich einige Verzögerungen bemerkt, aber nicht weiter beachtet.
Dann kam ein ShellyEM dazu, danach wurde es richtig langsam und schalten teilweise unmöglich.
ShellyEM macht richtig feuer und sendet jede Messwertänderung.
Da habe ich dann angefangen, aufzuteilen und seit dem läuft alles rund.
Achso, bei mir läuft alles auf einen TinkerboardS .
@Tom: Ja, die Probleme mit dem Shelly hatte ich mitbekommen. So richtig prickelnd ist das aber nicht erst dann zu reagieren wenn es zu spät ist. Diese MQTT Fehlermeldungen wegen dem Buffer gibt es auch hier im Minutentakt. Vermutlich kommens von dem HeishaMon Projekt welches die Wärmepumpe bedient.
Da die IPS Leute scheinbar selbst nicht recht wissen was die Ursache ist liegt es nahe vor Ort selbst zumindest mal einige Sachen abzuklären bzw. auszuschließen.
Bin dann zusätzlich gerade dabei einige meine alten Eigenbauten auf MQTT umzustellen. Vorher liefen die über verschiedenste Gateways, manches über ein selbst definiertes Protokoll über Server/Client Socket auch mit etwas höheren Datenrate. Wenn ich das nun neu aufsetze so wäre es natürlich gut vorher zu wissen wie weit man ungefähr gehen kann. Wär doch blöd wenns hinterher Ärger gib weil irgendwo ein Nadelöhr it.
Da ich gerade alle mein Bewegungsmelder auf Radar umstelle und die selbstgebaute Firmware der Nodes entsprechend anpassen kann stellt sich das alte Problem wieder: Welche Datenrate kann man denn dem MQTT Server so zumuten ?
Wie schon im Eingansgpost erwähnt, die Zenerpotenz als Richtwert würde schon mal reichen.
Etwas mehr zum Hintergrund: Mit den Radarteile bekomme ich die Position der Person im Raum als x/y Koordinaten. Das eröffnet natürlich ganz ander Möglichkeiten als es ein schnöder Piri Bewegungsmeder bietet.
Andererseits kann da aber auch einiges an Datenrate zusammenkommen, je nachdem ob die man Filterung und Zonenauswertung am Node oder in IPS macht.
Läuft alles am Node und ist man bei der Firmware entsprechend sorgfältig reduziert sich alles auf wenige Events = kein Probem.
Geht man aber den einfachen Weg und schickt die Rohdaten an IPS um es dann hier entsprechend zu verarbeiten, so ist das deutlich komfortabler, aber erzeugt auch Systemlast.
Weitere Frage: Was passiert wenn die Datenrate zu hoch wird ? Womöglich von mehreren Nodes gleichzeitig.
Werden Telegramme verschluckt ? Welche Telegramme werden verschluckt ? Laufen irgendwelche Queues voll ?
Das Radarthema hat dem WAF zu nie gekanntem Höhenflügen verholfen, das will ich mir jetzt nicht durch ungeschickte Konfiguration wieder kaputtmachen.
Der Server sollte alles schön nacheinander abarbeiten. Ggf. hast du Verzögerungen da sich eine Queue bildet. Das MQTT Server wird auch nicht das Problem sein. Die Frage ist eher, wie viele der Telegramme landet am Ende in wie vielen Variablen. Und werden die Variablen an die Visu weitergeleitet und wie viele Ereignisse hängen an diesen Variablen, die dann wieder etwas im System ausführen. Der Server sollte hier nicht das Bottleneck sein. Beobachte die CPU Last und ob du Verzögerungen im System bekommst. Verworfen werden sollte nichts.