Scheduling von Datenpolling

Hallo zusammen,

ich mache mir gerade Gedanken darum, wie ich am sinnvollsten ein kleines Schedulingproblem lösen kann.
Ich benötige ein Scheduling für Datenpolling Aufgaben im Sekunden oder ggf. auf Sub-Sekunden bereich, es soll so z.B. alle x sec ein neuer Datenabruf gestartet werden.

Ich habe mir hier bereits mehrere Scheduling Libs wie Quartz oder Hangfire angesehen und denke dass man das damit (vorallem Quartz) ganz gut lösen könnte, habe aber ein wenig Angst vor dem Overhead, den die Libs mitbringen.

Hat jemand hier ggf. bereits Erfahrungswerte?
In C/C++ hätte ich die Threads vermutlich einfach an eine Semaphore gehangen - den Weg versuche ich gerade einmal in C# zu konstruieren, bin mir aber relativ sicher, ob das der richtige Weg ist.

Edith sagt: Noch ein paar Infos sind vielleicht ganz hilfreich...
-> Basis Framework .net core 2.1
-> Laufzeitumgebung wird docker sein
-> Das Scheduling soll permanent laufen, die unterliegenden TCP Verbindungen werden separat verwaltet und debugged, es laufen im Scheduling dann "nur" die Applikationsschicht Clients
-> Nach dem Abfragen der Daten müssen diese noch von ushort[] in Zieldatentypen konvertiert werden, dies soll innerhalb des schedulten Task stattfinden
-> Transport Protokoll ist Modbus/TCP

Moin,

ich benutze Quartz in einigen Programmen von mir. Ich wüsste jetzt nicht, was da für ein Overhead entstehen soll? Meinst du den Ressourcenverbrauch? Der ist zu vernachlässigen.

Gruß
Khalid

Hi,

meine Bedenken (vermutlich unbegründet) liegen darin, dass ich in diesem Projekt begrenzte Ressourcen habe (es soll unter IoT Edge auf Win 10 IoT Core laufen) und dort Daten von externen Geräten einsammeln. Das soll möglichst schnell geschehen und soweit das möglich ist (immerhin reden wir von einer managed Sprache und einer Prozessvirtualisierung) deterministisch, sprich mit wenig Jitter.
Quartz hat bei meinen Tests da auch die besten Ergebnisse geliefert, ich habe leider die Zielhardware noch nicht, so dass ich da noch keine Tests mit machen konnte und bisher nur ein grobes Konzept.

Meine expliziten Bedenken sind, dass viele parallel vom Scheduler getriggerte Jobs gleichzeitig anlaufen und ich dann durch das erstellen der ganzen Objekte, suchen der TCP Verbindung usw.. einen relativ großen Overhead und damit eine Verzögerung reinbekomme.
Deswegen suche ich nach Erfahrungswerten. Ich habe Quartz selber schon eingesetzt, dabei aber eher sowas wie "mache alle 10 min etwas" auf einer Windows VM umgesetzt. Hier kann es auch darum gehen alle 200ms etwas zu triggern.

Quartz sehe ich relativ unkritisch, da das meiste alles beim Warmup passiert.

Wenn Du halbwegs deterministisch sein willst, dann solltest Du Dich vor allem beim Code zum Extrahieren der Daten und beim anschließenden Serialisieren anstrengen, effizient zu sein.
Da Du Dotnet Core 2.1 benutzt, solltest Du vor allem mit Span<T> arbeiten, damit Du nicht zu viele Arrays allozierst.

In jedem Fall würde ich Dir vor allem raten, daß Du mit BenchmarkDotnet für Performance Tests arbeitest und mit Perfview das Verhalten Deiner Applikation misst - insbesondere um das Verhalten das Garbage Collectors einschliesslich der Pausen nachvollziehen zu können.

Hallo,

damit Du nicht zu viele Arrays allozierst. ArrayPool verwenden. Ob dann auf die Arrays via Span<T> zugegriffen wird ist eine andere Geschichte (aber meist eine vorteilhafte).

mfG Gü

Danke, solche Erfahrungswerte bzw. Tipps habe ich mir versprochen 😃