Timer vs. Thread zur entkopplung!
-
Hallo , ich habe eine Cache Klasse, welche eine Queue nutzt um daten zu cachen, eine writeDate und getData Methode! dies sind syncronisiert!
In den cache werden daten von Komponente A in zufälligen intervallen geschireben. Komponente B liest dise daten zyklisch und loggt sie mit! Das Ganze mach ich um Komponente A und B zu entkoppeln um das system dynamisch zu halten. Das ganze funktniert auch einwandfrei, aber so:
Nun Frag ich mich, was PERFOMANTER ist die Daten zyklisch aus wieder aus dem Cache zu lesen.. soll ich da ein Timer nutzen( einfacher zu implementieren) oder soll ich das ganze mit nem Thread und Sleep umsetzen etc. umsetzen!
-
1. Ich würde einen Timer benutzen, da es natürlicher erscheint.
2. Es kommt drauf an was für ein Timer Du benutzt.
. a.) System.Timers.Timer -> hat keine bedeutung
. b.) System.Threading.Timer -> benutzt für die Callbacks eigene Threads
. c.) System.Windows.Forms.Timer -> benutzt den UI Thread für die Callbacks.Simon
Edit
Nun Frag ich mich, was PERFOMANTER ist die Daten zyklisch aus wieder aus dem Cache zu lesen.. soll ich da ein Timer nutzen( einfacher zu implementieren) oder soll ich das ganze mit nem Thread und Sleep umsetzen etc. umsetzen!
Über die Performance würde ich mir Gedanken machen, wenns nicht mehr reicht!
-
Ich hab ne Systemauslastung von 96% (3GHz /1GB ram) für meinen Datelogger.. und das ist nur die Testversion!!
Wie sieht es mit den Callbacks aus? Nehmen wir an ich hab nen Timer zyklus von 50 ms.. der Funktionaufruf des Callbacks dauer aber meinentwegen 100ms.. was passiert dann? Wie kann ich gewährleisten, das die Timer Cache Klasse erste zerstört wird, wenn alles Timmer- callback aufrufe fertig sind?
-
96%!? Das ist hart, wie loggst du wenn ich fragen darf?Eventuell liegt das Performanceproblem da.
-
Ja ich logge momentan in eine Access Datenbank.. in der Testversion schiese ich 320 Einträge alles 100ms in den Cache... für jeden eintrag "muss" ich ne INSERT INTO anweisung amchen.. denke mal daran liegt das Performance problem!
-
denke mal daran liegt das Performance problem!
Denken ist gut, messen ist besser. Nimm ein Profiler zur Hand!
-
Syncroniszer schrieb:
... Wie kann ich gewährleisten, das die Timer Cache Klasse erste zerstört wird, wenn alles Timmer- callback aufrufe fertig sind?
Was meinst du damit? Die Cachklasse sollte erst dann zerstört werden wenn alle Aufrufe durch sind. Vorher müsste da nichts zerstört werden, aber erklär mal etwas präziser. rufst du explizit Dispose für irgendwas auf oder so?
-
ja ich will die Ressourcen sprich Datenbank ja wieder freigeben, aber bevor ich das tue müssen erst die rest daten des Caches da rein geschrieben werden, bevor sich die Anwenung zersört wenn man sie schliesst!
-
Syncroniszer schrieb:
ja ich will die Ressourcen sprich Datenbank ja wieder freigeben, aber bevor ich das tue müssen erst die rest daten des Caches da rein geschrieben werden, bevor sich die Anwenung zersört wenn man sie schliesst!
da dürfte dein Problem liegen ... die Resourcen für die DB - also den Zugriff - holst Du vor dem ersten Log-Vorgang ... nach dem letzten Log-Vorgang - also Ende des Programms - kannst Du sie wieder frei geben ... dazwischen wird sich nicht viel Ändern beim Zugriff auf die DB
hand, mogel
-
Ja das mach ich jetzt schon, ich lasse die Datenbank solange offen bis sie nich mehr gebraucht werde, d.h. ich hab ein Archiv Managment Stratigie Klasse welche das aktuell verwendet archiv (entsprechend periode oder größe etc.) bereitstellt.. und dise lasse ich permanent offen, d.h. daran kann es NICHT liegen!
-
theta schrieb:
Denken ist gut, messen ist besser. Nimm ein Profiler zur Hand!