Inoffizielles deutsches Xbase-Forum

Hallo,

bei meinem Kunden ist ein merkwürdiges Phänomen aufgetaucht. Die Umgebung ist: Die Programme liegen auf einem Windows Server 2016 auf gemappten Laufwerken, werden lokal auf den Clients aufgerufen. Per Directory() werden in dem Programm Verzeichnisse ausgelesen, die ebenfalls auf einem gemappten Server-Laufwerk liegen, dabei werden Filterbedingungen eingesetzt (z. B. muß der Dateiname mit der korrekten Kundennummer beginnen, und die Dateiendung soll ".pdf" sein).

Das funktioniert schon seit Jahren einwandfrei. Aber seit dem Update auf 1803 dauert solch ein Directory()-Aufruf locker 1 Minute. Oder auch schon mal wesentlich mehr. Bei allen Rechnern mit Build 1709 oder älter geht das weiterhin in Sekundenbruchteilen.

Kennt jemand von Euch das Phänomen?

Irritierend ist, daß das nicht immer und überall so ist. Es gibt in dem Netzwerk zwei Rechner mit 1803, wo das überhaupt keine Verzögerungen gibt. Und selbst bei mir ist das unterschiedlich. Gehe ich von meinem Rechner bei dem Kunden mit 1803 in das produktive System, dann dauert das ewig. Gehe ich in das Entwicklungsverzeichnis mit eigenen Verzeichnisstrukturen für die Directory()-Aufrufe, geht das normal schnell. Also vom gleichen Client aus unterschiedliche Ausführungen.

Jan

Falls es Dich beruhigt: Das ist bei mir auf Arbeit schon ewig so - allerdings Windows 7 Enterprise und Novell

Viele Grüße,
Martin

Hallo Martin,

nee, das beruhigt mich jetzt nicht wirklich. Mein Kunde findet das nämlich gar nicht witzig. Wenn die jetzt eine Dateiaufstellung haben wollen, oder eine PDF drucken wollen, dann dauert das mal locker 10 Minuten, bis das gelaufen ist. Arbeitsfluß sieht anders aus, gerade wenn man einen Kunden am Hörer hat und die Aufstellungen für das Gespräch braucht.

Und es lief ja auch anders. Erst das Update hat das "zerstört".

Jan

Hast du mal probiert, ob es bei directory()-Aufrufen per UNC-Pfad statt gemappte Laufwerke andere Zeiten gibt ?

hallo Wolfgang,

interessante Idee. Muß ich mal testen.

Wobei das wirklich nur ein Austesten sein kann. Praktikabel dürfte das bei dem Kunden eher nicht sein. Muß ich mal schauen.

Jan

Mein Rechner (Win7) hat bei gut gefüllten Verzeichnissen selbst im Explorer teilweise 5 bis 6 Sek. die drehende Sanduhr und das lokal.
Im Netz wird es als noch schlimmer (NAS) - ich frage mich immer wieder wieso das heute so lange dauert, was früher sofort da war ...

Hubert,

in den betreffenden Verzeichnissen liegen teilweise 100 GB an Dateien. Bis 1709 lief das trotzdem sowas von schnell, unter 1 Sekunde immer. Erst 1803 macht Probleme.

Jan

Es ist nicht die Dateigröße als solche, die bremst, sondern die Datei Anzahl !
Es soll auch eine Rolle spielen, ob die Dateilänge über den alten 8.3 Namen liegt und ob die Verarbeitung den Langnamen oder Kurznamen nutzt - da war ein Schalter in der INI - aber ich kann mich nicht mehr erinnern.
Zu den Win 10 Versionen kann ich allerdings nix sagen.

Hubert,

geh mal von ca. 100.000 Dateien je Verzeichnis aus.

Jan

Hallo, Jan -


ich kann da auch nur Gedankenanstösse liefern, wie ich das angehen würde.

Zum einen würde ich eine 1709 Version wiederherstellen (die kompletten Installationsdateien werden in AppData abgelegt) und beide Versionen mal parallel laufen lassen, um zu prüfen, ob es wirklich am Wechsel der Xbase++-Version liegt.

Dann würde ich schauen, wie lange ein "dir *.pdf" in cmd.exe braucht.

Möglicherweise wurde bei Deinem Kunden parallel auch was an der Netzwerkstruktur gedreht (ja, ich weiss, die haben da bestimmt NICHTS gemacht, aber wie fragt der erfahrene Supporter immer so nett: "Und was haben Sie getan, bevor Sie nichts getan haben?").

Jan hat geschrieben: ↑Di, 12. Jun 2018 9:29 Aber seit dem Update auf 1803 dauert ...

Jan meint sicherlich den Update der Win 10 Version, nicht der von Xbase++

100.000 Dateien sind wirklich sehr viel Holz im Verzeichnis.

Hubert,


da hast Du recht. Aber in einem solchen Fall würde ich mich als Software-Lieferant nicht in der Pflicht sehen (klar, ich würde versuchen, das zu beheben, aber wenn M$ da was verbockt hat) ...

... wenn Alaska bei 1803 wäre, dann hätte ich da ein paar Updates zwischendurch verpennt ...

Ja klar sind 100.000 Dateien eine ganze Menge. Der Explorer braucht auch ca. 20 Sekunden, um die alle aufzulisten. Aber das Directory() von Xbase++ war da echt flott (bzw. ist es noch auf den älteren Builds).

Und doch, ich als Softwareentwickler bin da in der Pflicht. Vielleicht nicht rechtlich. Aber mental, partnerschaftlich, freundschaftlich,..., dann doch. Mein Kunde hat ein Problem, das sollte ich wenn irgend möglich beheben. Egal wer Schuld daran ist.

Alaska kennt das Problem übrigens nicht. Aber das hatten die mir auch damals gesagt, wo das mit den Programmabstürzen bei Auflösungen größer FullHD kam. Erst später haben die gemerkt, das ich da wohl doch Recht hatte mit meiner Meldung. Das soll nicht heißen, daß das hier zwingend wieder so ist. Der Admin meines Kunden ist da gerade am testen (Virenscanner, Treiber, SSD-Probleme mit 1803, usw.). Wir forschen da halt in alle Richtungen.

Jan

Wo ist Jimmy mit seiner SMB1-Abschalten-Manie in den neuesten Win10-Versionen

Servus,
das Geschwindigkeitsproblem gab's bei älterer/schwächerer Hardware bzw. "langsamem" Server auch schon früher.
Bei Verzeichnissen mit Zigtausend Dateien war der Zugriff langsam. Explorer von Windows oder auch directory() Funktion.
Um dies zu vermeiden lege ich die Dateien in verschiedenen Verzeichnissen ab.
In meinem Fall ist das ein Archivierungssystem für Dokumente, Bilder, Scans usw.
Die Struktur schaut in etwa so aus:
\MeinArchiv\2018\01
\MeinArchiv\2018\02
\MeinArchiv\2018\03
und so weiter.
In der Regel befinden sich in den Verzeichnissen dann weniger als 5.000 Dateien, der Zugriff über den Explorer ist schnell
In meinem Programm erfolgt der Zugriff auf die Dokumente über eine Steuerdatei (Kunden-ID, Dokumentbeschreibung, Ablageort)
Mein "größter" Anwender hat inzwischen über 350.000 Dateien archiviert.

Gruß Stefan

Stefan et al.,

wir brauchen hier nicht über Hardwaregeschwindigkeit, Netzwerkperformance, Anzahl der Dateien, etc. zu reden.Denn der Punkt ist (ich wiederhole mich da gerne): Unter 1709 und älter ging das ruck zuck. Verzögerung ca. ein Augenzwinkern. Unter 1803 dauert das mind. 100x so lange. Bei ansonsten gleicher Software, Hardware, etc.

Jan

Hallo Jan

ein directory() Aufruf mit der Maske i*.* dauert bei meinen Testrechnern (alle unter 1803) ca. 0.7 Sek. im Array sind dann 8124 Dateieinträge. Eine andere Maske liefert 30 Dateieinträge in 0.3 Sek. das Verzeichnis mit 40100 Dateien liegt auf einem gemappten Laufwerk mit Laufwerkbuchstabe angesprochen. Antivirus eingeschaltet. Verwendet wird SMB-3

Gruss Carlo

HaPe hat geschrieben: ↑Di, 12. Jun 2018 16:43 Wo ist Jimmy mit seiner SMB1-Abschalten-Manie in den neuesten Win10-Versionen

Tja ... ich kann mich nur wiederholen

https://www.deskmodder.de/blog/2018/06/ ... -in-sicht/

Jimmy,

Das Update von gestern hat keine Änderung gebracht.
Abschalten der Client-Firewall ebenfalls nicht.

Das wars also eher nicht. Konnte ja auch nicht, denn der Artikel bezieht sich auf ältere Server-Software. bei meinem Kunden ist aber wie beschrieben Windows Server 2016 im Einsatz.

Jan

> Das Update von gestern hat keine Änderung gebracht.

wieso sollte es
SMB1 ist default ausgeschaltet und das wird sich nicht ändern.

> Abschalten der Client-Firewall ebenfalls nicht.

wie schaltest du den Windows Firewall ab

> denn der Artikel bezieht sich auf ältere Server-Software.

JA ... das Problem IST eben schon seit 2012

Der Link ist ein Hinweis welche Problem das Abschalten vom SMB1 nach sich zieht.
natürlich gehören noch viel mehr Dinge dazu ... aber das wisst ihr ja alle über SMB1, oder

ABER wenn es das SMB1 Problem wäre, wäre es schon länger da gewesen. JAN hat aber erst seit kurzem mit WIN 10 Build 1803 sein Problem.

Danke Hubert.

Um ehrlich zu sein: Ich kann dieses SMB1-Gerede nicht mehr hören.

Jan

Hallo Jan,

www.google.com
Suche auf "Letzter Monat"
Directory() windows server 2016 1803 smb1

LG
Otto

Kommt ein Windows 10 V1803 SMBv1-Fix zum Juni 2018-Patchday?

Publiziert am 9. Juni 2018 von Günter Born


[English]Kleine Info für Benutzer des Windows 10 April Update, die mit Problemen im Netzwerk und möglicherweise bei Multifunktionsgeräten mit Netzwerkscans geschlagen sind. Wie es ausschaut, arbeitet Microsoft daran, im Juni (Patchday wäre der 12. Juni 2018) einen Fix für das ‘SMBv1-Problem’ bereitzustellen. Nachfolgend habe ich mal einige Informationen zum Thema bereitgestellt.

brandelh hat geschrieben: ↑Do, 14. Jun 2018 8:12 ABER wenn es das SMB1 Problem wäre, wäre es schon länger da gewesen.
JAN hat aber erst seit kurzem mit WIN 10 Build 1803 sein Problem.

na und ...

seit 1709 ist z.b der Dienst „Unterstützung für SMB 1.0 aktivieren" NICHT eingeschaltet.
das sich nun mit der 1803 "bei einigen" Probleme zeigen hängt zwar auch mit einem BUG im Windows Defender / Firewall zusammen aber siehe dir mal an welche Ports gemeint sind : 135-139 also genau die UDP Port welche SMB1 verwendet.

Jan hat geschrieben: ↑Do, 14. Jun 2018 8:14Um ehrlich zu sein: Ich kann dieses SMB1-Gerede nicht mehr hören.

na dann brauchst du ja auch keine Tipps ...