ThingWorx Modelldefinition in Composer > System > Untersysteme > Sortiertes Ereignisverarbeitungs-Untersystem
Sortiertes Ereignisverarbeitungs-Untersystem
Das sortierte Ereignisverarbeitungs-Untersystem soll sicherstellen, dass bei der Verarbeitung von Ereignissen wie dem Binden und Aufheben der Bindung die richtige Reihenfolge beachtet wird. Das Untersystem stellt eine Fassade für einen Thread-Pool bereit und hat ähnliche Optimierungsparameter wie andere, beispielsweise das Untersystem für Ereignisverarbeitung. Derzeit bedient dieser Pool nur Präsenzauswertungen, die von Ereignissen zum Binden/Aufheben der Bindung ausgelöst werden.
Die in der folgenden Tabelle beschriebenen Einstellungen dienen dazu, den Speicherbedarf zu begrenzen, wenn das System stark ausgelastet ist. Wenn diese überschritten werden, wird isReporting für Dinge unabhängig vom Gerätestatus in false geändert. (Weitere Details finden Sie unten in der Tabelle.)
Einstellung
Beschreibung
Mindest-Anzahl der dem Ereignis-Verarbeitungspool zugeordneten Threads
Mindestanzahl von Threads, die zugeteilt werden. Diese Einstellung bestimmt auch die ursprüngliche Größe des Thread-Pools. Wenn sich Threads im Leerlauf befinden, werden sie zur Beibehaltung von Ressourcen bis zu dieser Anzahl reduziert.
Maximale Anzahl der dem Ereignis-Verarbeitungspool zugeordneten Threads
Maximale Anzahl von Threads, die zugeteilt werden. Der Pool ändert unter Last bis zu dieser Anzahl dynamisch seine Größe.
Maximale Anzahl an Warteschlangeneinträgen bevor ein neuer Arbeitsthread hinzugefügt werden kann
Maximale Anzahl von Aufgaben (Präsenzauswertungen), die sofort verarbeitet werden können, bevor der Pool seine Größe ändert.
Maximal blockierte Aufgaben, um eine ordnungsgemäße Ausführung zu garantieren
Maximale Anzahl von Aufgaben (Präsenzauswertungen), die in der Warteschlange auf eine vorherige Auswertung auf demselben Gerät warten können.
Beachten Sie, dass die ersten drei Einstellungen auch im Untersystem für Ereignisverarbeitung verwendet werden.
Das Untersystem unterscheidet zwischen zwei verschiedenen Gründen, aus denen eine Aufgabe blockiert werden kann:
Nicht genügend Worker-Threads sind verfügbar, um alle Auswertungen bei ihrem Auftreten in Echtzeit zu verarbeiten. Mit der Einstellung "Maximale Anzahl an Warteschlangeneinträgen" können Sie die Wahrscheinlichkeit des Auftretens dieser Situation einschränken.
Alternativ können dieselben Geräte flackern und zahlreiche Auswertungen erforderlich machen. Wenn eine Auswertung nicht abgeschlossen wird, bevor das nächste Ereignis zum Binden/Aufheben der Bindung auftritt, muss die zweite Auswertung warten, bis die erste abgeschlossen ist. Die Einstellung "Maximale blockierte Aufgaben" steuert, wie viele Auswertungen auf diese Weise beendet werden können.
Wenn der Grenzwert für "Maximale Anzahl an Warteschlangeneinträgen" überschritten ist, versucht der Thread-Pool, seine Größe selbst zu ändern. Wenn die Aktion erfolgreich ist, hilft der neue Worker-Thread, die Warteschlange der Auswertungen abzuarbeiten.
Wenn seine Größe aufgrund des Grenzwerts "Max Threads" nicht geändert werden kann oder wenn der Grenzwert "Maximal blockierte Aufgaben" überschritten wird, lehnt der Thread-Pool die Auswertung ab. Eine zurückgewiesene Auswertung führt sofort zu einer fehlenden Berichterstattung ohne weitere Verarbeitung.
War dies hilfreich?