Nabend! (Oder guten Morgen:-)) Ihr erinnert euch noch an den Thread "Aussetzer beim Dateizugriff"?
Habe nun einen etwas größeren Versuch gefahren, um das Ganze "nachzustellen". Habe als "unzuverlässige" Netzwerklaufwerke auch mal den HiDrive von Strato via Internet und auch einen USB Stick an einer Fritzbox mit eingebunden.
Ergebniss:
VB2010 reagiert bei Problemen beim Dateizugriff (egal welcher Art) wesentlich "allergischer", als noch ein VB6. Es kommt im Schnitt zu wesentlich mehr und längeren Aussetzern, die meistens nur die zugreifende Anwendung betreffen, hier aber manchmal sogar ActiveX in getrennten Threads beeinflussen, und in bestimmten Situationen sogar die ganze Maschine in einen 10s "Schluckaufmodus" versetzen können. Mit "Problemen" meine ich hier auch ausdrücklich so etwas "banales" wie Zugriffszeiten im 100-500ms Bereich, die man im normalen Netzwerk nicht kennt. Aber selbst bei Antwortzeiten von nur wenigen ms (weil vielleicht grad mehrere Clients auf eine Dateifreigabe auf einen etwas älteren PC zugreifen), lassen sich deutliche Unterschiede ausmachen.
Richtig "gut" läßt sich sowas anscheinend tatsächlich nur handeln, wenn man tatsächlich jeden Zugriff in einen eigenen Thread auslagert. Natürlich nur mit erheblichen (Design) Aufwand, den so ein MultiThreading mit sich bringt. (Diesbezüglich nochmal herzlichen Dank an meine Helfer aus diesem Forum)
Damit habe ich nun zwar mein ursprüngliches Problem (stotternde Webcams) in den Griff bekommen. Aber: Die Frage nach dem "Warum" bleibt offen!
Hat hier jemand eine Idee, warum VB2010 / Net speziell bei Dateizugriffen in einem Netzwerk diesbezüglich so reagiert? Ich bin doch mit Sicherheit nicht der erste, der darüber gestolpert ist. (Aber ich bin leider einer derjenigen, die wohl noch sehr oft darüber stolpern werden!
Und: Weiß jemand, ob beim ständigen Erzeugen und Beenden von Threads "Folgeschäden" in Form von Speicherfraß auftreten? Sollte man stattdessen vielleicht besser einige wenige "Nebenthreads" erzeugen, die dann aber immer aktiv bleiben? Ich beschäftige mich hauptsächlich mit Programmen, die "NonStop" laufen sollen. Uptimes von teilweise mehreren Monaten sind keine Seltenheit. Da wäre ein "Speicherfresser" natürlich ein KO Kriterium.
Habe nun einen etwas größeren Versuch gefahren, um das Ganze "nachzustellen". Habe als "unzuverlässige" Netzwerklaufwerke auch mal den HiDrive von Strato via Internet und auch einen USB Stick an einer Fritzbox mit eingebunden.
Ergebniss:
VB2010 reagiert bei Problemen beim Dateizugriff (egal welcher Art) wesentlich "allergischer", als noch ein VB6. Es kommt im Schnitt zu wesentlich mehr und längeren Aussetzern, die meistens nur die zugreifende Anwendung betreffen, hier aber manchmal sogar ActiveX in getrennten Threads beeinflussen, und in bestimmten Situationen sogar die ganze Maschine in einen 10s "Schluckaufmodus" versetzen können. Mit "Problemen" meine ich hier auch ausdrücklich so etwas "banales" wie Zugriffszeiten im 100-500ms Bereich, die man im normalen Netzwerk nicht kennt. Aber selbst bei Antwortzeiten von nur wenigen ms (weil vielleicht grad mehrere Clients auf eine Dateifreigabe auf einen etwas älteren PC zugreifen), lassen sich deutliche Unterschiede ausmachen.
Richtig "gut" läßt sich sowas anscheinend tatsächlich nur handeln, wenn man tatsächlich jeden Zugriff in einen eigenen Thread auslagert. Natürlich nur mit erheblichen (Design) Aufwand, den so ein MultiThreading mit sich bringt. (Diesbezüglich nochmal herzlichen Dank an meine Helfer aus diesem Forum)
Damit habe ich nun zwar mein ursprüngliches Problem (stotternde Webcams) in den Griff bekommen. Aber: Die Frage nach dem "Warum" bleibt offen!
Hat hier jemand eine Idee, warum VB2010 / Net speziell bei Dateizugriffen in einem Netzwerk diesbezüglich so reagiert? Ich bin doch mit Sicherheit nicht der erste, der darüber gestolpert ist. (Aber ich bin leider einer derjenigen, die wohl noch sehr oft darüber stolpern werden!
Und: Weiß jemand, ob beim ständigen Erzeugen und Beenden von Threads "Folgeschäden" in Form von Speicherfraß auftreten? Sollte man stattdessen vielleicht besser einige wenige "Nebenthreads" erzeugen, die dann aber immer aktiv bleiben? Ich beschäftige mich hauptsächlich mit Programmen, die "NonStop" laufen sollen. Uptimes von teilweise mehreren Monaten sind keine Seltenheit. Da wäre ein "Speicherfresser" natürlich ein KO Kriterium.