APPEND FROM resp. DbIMPORT verlangsamt in LAN W2k8 / WinXP

[Daniel]

Neue Performance-Probleme sind aufgetaucht, diesmal bei APPEND FROM für eine temp. Report-DB.
Es handelt sich um ein kleineres Network mit Windows Server 2008 und 4 WindowsXP-Workstations gemischt mit neuer Windows7-Workstation.
Neu würde man natürlich DbIMPORT() statt APPEND FROM verwenden.

Das Programm macht folgendes:
Für eine Auswertung wird eine temp. Datei aus einem Array erzeugt mit DbCREATE( "tpAbo", aDbfAbo).
- Das funktioniert normal. Dann folgt

Code: Alles auswählen

APPEND from ABO for eroeff >=vdatum .and. eroeff <=bdatum .and. !deleted()

Die Datei ist nicht übermässig gross.

Dieser Append funktioniert ein- zwei- oder dreimal normal und schnell. Dann jedoch plötzlich extrem verlangsamt, exakt wie wenn jemand auf dem Schlauch stehen würde! Dies z.B. auch, wenn ich von der Win7-Workstation auf die WinXP-WS wechsle und das Programm dort neu starte.
Natürlich habe ich alle CLOSE DATA und RELEASE ALL kontrolliert. Zudem passiert es auch, wenn die Anwendung verlassen wurde, wobei ja schon von XBase und auch von Windows her standardmässig alle Ressourcen freigegeben werden müssen.

[Daniel]

Hat das etwa auch wieder mit SMB zu tun, oder mit irgendwelchen Einstellungen in der Registry?
Wie müssten denn diese Einstellungen sein, damit es richtig funktioniert?

Das Seltsame ist, dass es vorher ohne Schwierigkeiten gelaufen ist. Bloss kopiere ich jetzt zuerst die DB, bevor ich sie für den Report auswerte. Dies, weil ev. andere User die DB ändern.

[AUGE_OHR]

hi,

versuch mal http://support.microsoft.com/kb/825433

[AUGE_OHR]

Hat das etwa auch wieder mit SMB zu tun, oder mit irgendwelchen Einstellungen in der Registry?

kurz gesagt : zu SMB1 "Problemem" gehören mindestens 2 Workstationen.

Zudem passiert es auch, wenn die Anwendung verlassen wurde, wobei ja schon von XBase und auch von Windows her standardmässig alle Ressourcen freigegeben werden müssen.

d.h. du bis "alleine" im Netzwerk ? wenn ja hat das nichts mit SMB1 zu tun.

der angegebene KB Link besteht ja auch 2 Teilen wobei der 2nd Teil ein Reistriy Eintrag ist.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lanmanworkstation\Parameters\DisableFlushOnCleanup -> 1 (on)

Tip : Taskmanager -> Resourcen -> Netzwerk die Ports von den Workstation kontrollieren und sich die "Linien / Peaks" im Diagramm beim APPEND ansehen.

[Tom]

Mal lokal ausprobiert? Enthält "ABO" Memofelder?

[Daniel]

Danke, Jimmy,

ja ich werde diesen Parameter in der Registry kontrollieren.

[brandelh]

Könnte es sein, dass zwei Arbeitsstationen gleichzeitig den Import einleiten ?

[Daniel]

Ja, Tom, lokal läuft alles prima,
und nein, ABO enthält keine Memofelder. Und die Zieldatei "TpAbo" nur diese 6 hier:

Code: Alles auswählen

  AADD( aDbf,{"LDatum","D", 8, 0} )
  AADD( aDbf,{"Tour" , "N", 3, 0} )  
  AADD( aDbf,{"Kunr" , "N", 8, 0} )
  AADD( aDbf,{"ArtGr", "C", 2, 0} )
  AADD( aDbf,{"ArtNr", "N", 8, 0} )
  AADD( aDbf,{"ArtAnz","N", 8, 0} )

( aDbf habe ich oben zur Verdeutlichung "aDbfAbo" genannt)

Hallo Hubert
naja, theoretisch wäre es möglich, aber praktisch kommt das kaum vor. Bei den Tests war es auf jeden Fall nicht der Fall.
Was ich mich aber gefragt habe: ob der Server irgendwelche schon längst geschlossene Files noch offen behält?

[AUGE_OHR]

Was ich mich aber gefragt habe: ob der Server irgendwelche schon längst geschlossene Files noch offen behält?

dafür gibt es den Resourcemonitor des Servers.

den Effekt den du beschreibst kennt man doch vom USB Stick / HD wenn man "grosse" Dateien überträgt.
der Explorer zeigt zunächst "unrealistische" Werte (Cache) an bevor er sich ein-pendelt bei einer konstanten Übertragungsrate.
die Frage ist aber wie der Server die Daten "sendet" ob "konstant" oder mit "Peak" ... und auf welchem Port.

also beobachte den Resourcemonitor des Server wenn du dein DbImport von der Client Workstation machst "was" in dem Moment passiert wo es beim Client langsam wird.

[Daniel]

die Frage ist aber wie der Server die Daten "sendet" ob "konstant" oder mit "Peak" ... und auf welchem Port.
also beobachte den Resourcemonitor des Server wenn du dein DbImport von der Client Workstation machst "was" in dem Moment passiert wo es beim Client langsam wird.

Ja, wenn ich das nächste Mal dort hingehe, werde ich das analysieren.
Der Kunde sagt, er hat mit dem Netzwerker alles geprüft und Updates gemacht, auch in Bezug auf den oben erwähnten KB825433, was ich angemahnt hatte. Aber das Problem müsse bei meinem Programm liegen.

Ich werde dann kontrollieren, ob der Parameter "DisableFlushOnCleanup" bei XP wirklich auf "1" steht, aber viel mehr ins Detail kann ich nicht gehen, ich bin ja da kein Spezialist und es fehlt mir die Zeit, mich in all diese Netzwerk-Einstellungen einzuarbeiten.
Ich meine auch, es kann nicht die Aufgabe des Applikations-Entwicklers sein, all diese Netzwerk-Sachen ins Detail zu studieren, nur um schliesslich nachweisen zu können, ob das Problem doch dort oder in meinem Programm liegt.

Müsste ich eventuell im Netzwerk ganz auf USE EXCLUSIVE verzichten, auch wenn ich nur eine temp. DB für einen Report auswerte?
Oder muss ich die DBF in einen Array umwandeln und so verarbeiten?

[brandelh]

Wenn das Programm als einziges auf eine Temporäre Datei (mit einmaligem Namen) zugreift, kann man die ruhig exclusive öffnen (ist auch schneller dann).
Die Datei AUS der appended wird, müsste automatisch immer shared read only geöffnet werden.
Kann es sein, dass das Programm zweimal läuft und versucht die gleiche Datei zu öffnen ?

Ansonsten sind Arrays natürlich ein guter Zwischenspeicher für normale Dateien (unter 1000 Datensätze).

[Daniel]

Eben so ist es, die temp. Datei wird exclusive geöffnet, und bei DbAppend() wird die Herkunftsdatei shared read only geöffnet.
Am Anfang war es tatsächlich so, dass ich die Datei zuerst geöffnet habe (vor dem DbAppend ), dann war sie plötzlich zweimal geöffnet. Aber das habe ich geändert.

Arrays: nein, es sind schon deutlich mehr als 1000 Datensätze. Das fällt also wahrscheinlich weg.
Zudem müssen sie nachher indiziert werden, um sie für den Report zu summieren.

[AUGE_OHR]

Der Kunde sagt, er hat mit dem Netzwerker alles geprüft und Updates gemacht, auch in Bezug auf den oben erwähnten KB825433, was ich angemahnt hatte. Aber das Problem müsse bei meinem Programm liegen.

hat er wirklich bei "jeder" Workstation den Eintrag in der Registry eingetragen ... nun das kannst du ja "kontrollieren".

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lanmanworkstation\Parameters\

lies doch einfach alle Parameter aus und "vergleiche" diese mit den "gewünschten" für die Workstation

Ich werde dann kontrollieren, ob der Parameter "DisableFlushOnCleanup" bei XP wirklich auf "1" steht, aber viel mehr ins Detail kann ich nicht gehen, ich bin ja da kein Spezialist und es fehlt mir die Zeit, mich in all diese Netzwerk-Einstellungen einzuarbeiten.

früher gab es einen Administrator ... und das nicht nur nebenbei ...

Müsste ich eventuell im Netzwerk ganz auf USE EXCLUSIVE verzichten, auch wenn ich nur eine temp. DB für einen Report auswerte?
Oder muss ich die DBF in einen Array umwandeln und so verarbeiten?

wie Huber schon sagte ist USE EXCLUSIVE das schnellste/sicherste ... aber wenn du eine TEMP.DBF hast ... ( doch nicht auf dem Server ? ) heisst es das er auch "schreiben" muss ...

also warum nicht alles in ein Array "einlesen" was du hinter "ausdrucken" willst ?
p.s. ändere nicht deinen Source Code sondern eine #include "DBF2ARRAY.CH"
wo der Feldname zu einer Array #define Konstante wird ... nur der Alias ( -> ) muss korrigiert werden.

[Daniel]

lies doch einfach alle Parameter aus und "vergleiche" diese mit den "gewünschten" für die Workstation

Müsste ich erst mal herausfinden, wie ich die alle auslese - ohne sie gleich mit dem RegEdit zu öffnen bis in alle Äste hinaus.

[...] früher gab es einen Administrator ... und das nicht nur nebenbei ...

Gibt es schon, aber für ein KMU kommt er nur vorbei wenn nötig, und der setzt lieber nur Defaults. Ihm die Bedürfnisse einer datenbasierten Applikation verständlich zu machen, ist schwierig, wenn man nicht auf "offizielle" Dokumente verweisen kann.

Müsste ich eventuell im Netzwerk ganz auf USE EXCLUSIVE verzichten, auch wenn ich nur eine temp. DB für einen Report auswerte?

wie Hubert schon sagte ist USE EXCLUSIVE das schnellste/sicherste ... aber wenn du eine TEMP.DBF hast ... ( doch nicht auf dem Server ? ) heisst es das er auch "schreiben" muss ...

Ok, hier habe ich USE EXCL mit den EXCLUSIVE OpLocks durcheinandergebracht.
Aber wieso soll es dann ein Problem sein, wenn ich in eine temp. DB, die EXCL ist, auch schreibe, bis ich die Daten zusammen habe. Dann kann ich sie für andere Kriterien indizieren und auswerten.

[brandelh]

Ich nutze in meinem Programm eine temporäre DBF um die Zeiträume abzugleichen.
Diese wird mit USE EXCLUSIVE erstellt (Dateiname: cFix+dtos(date())+cUserName+time())
Du kannst natürlich auch eine andere Funktion verwenden um einen eindeutigen Namen zu erzeugen,
aber er muss halt auf jeden Fall für verschiedene PCs / USER / Programminstanzen einzigartig und unbenutzt sein.

[Herbert]

Immer wieder und wieder: Was machen deine Virenscanner? Blockieren die was?

[brandelh]

[...] früher gab es einen Administrator ... und das nicht nur nebenbei ...

Gibt es schon, aber für ein KMU kommt er nur vorbei wenn nötig, und der setzt lieber nur Defaults. Ihm die Bedürfnisse einer datenbasierten Applikation verständlich zu machen, ist schwierig, wenn man nicht auf "offizielle" Dokumente verweisen kann.

Es gibt eine PDF Datei: xpp-compilation-de.pdf (aus xpp-compilation-de.ZIP - 19.01.2010) von Alaska, dort wird einiges zum SL1 / ActiveX etc. erwähnt.
UND auf Seite 17, 18 registry-keys und Einstellungen. Es kann sein, dass es das nur über den Accout / Dokumente gibt, notfalls mal bei Alaska nachfragen.

[AUGE_OHR]

Aber wieso soll es dann ein Problem sein, wenn ich in eine temp. DB, die EXCL ist, auch schreibe, bis ich die Daten zusammen habe. Dann kann ich sie für andere Kriterien indizieren und auswerten.

"wo" ist die temp DBF, das ist hier die Frage ?!
wenn die auf dem Server erzeugt wird hast du u.U. erhebliche Last beim "schreiben" erzeugt !

wenn die "local" liegt "sollte" deine Festplatte schnell genug sein ... aber RAM ist "schneller"
wenn man ein zusätzliches Element in ein Array aufnimmt kann man das sehr schön als "Index" nutzen.
s.h. C:\ALASKA\XPPW32\Source\samples\basics\GuiBrow\FBROWSE.prg

[Daniel]

Also, wenn eine Datei EXCL USE'd wird, darf sie niemand anderer verwenden, - aber auch nicht verwenden wollen. Demzufolge einen einzigartigen Dateinamen verwenden.

- Virenscanner:
Ja, Herbert, das ist und bleibt eine Baustelle, den Leuten klar zu machen, was die Virenscanner für Probleme verursachen. Tom hat das ja schön erklärt (Merkblatt Virenscanner), es ist wie wenn bei jedem Anfahren mit dem Auto ein Mechaniker aus dem Gebüsch springt, um den ganzen Wagen durchzuchecken ...
Wir haben die zwar beim Testen ausgeschaltet, doch bin ich nicht sicher, ob nicht sogar auf dem Server noch so ein Bremser läuft / gelaufen ist.
Ich hatte jedenfalls schon verschiedentlich entsprechende Fehlermeldungen (file create, open) die vom Anwender "natürlich" dem Programm angelastet werden ...

[Daniel]

"wo" ist die temp DBF, das ist hier die Frage ?!
wenn die auf dem Server erzeugt wird hast du u.U. erhebliche Last beim "schreiben" erzeugt !

wenn die "local" liegt "sollte" deine Festplatte schnell genug sein ... aber RAM ist "schneller"
wenn man ein zusätzliches Element in ein Array aufnimmt kann man das sehr schön als "Index" nutzen.
s.h. C:\ALASKA\XPPW32\Source\samples\basics\GuiBrow\FBROWSE.prg

Temp-Dir: Früher hatten wir jeweils ein "SET TmpDB" ins Environment geschrieben, doch das wurde immer häufiger vergessen, weil es nicht mehr üblich ist. Jetzt kann man es im Programm einstellen, und der Kunde wollte es auf den Server tun...

Gut, danke, mal schauen, ob ich das auf Array umbauen kann. - Es sind aber viele Sätze, so zwischen 15'000 und 40'000, wenn ich mich richtig erinnere (muss mal nachschauen).

[AUGE_OHR]

Temp-Dir: Früher hatten wir jeweils ein "SET TmpDB" ins Environment geschrieben, doch das wurde immer häufiger vergessen, weil es nicht mehr üblich ist. Jetzt kann man es im Programm einstellen, und der Kunde wollte es auf den Server tun...

wenn es auf den Server geht und der keine SSD hat ...

bei SET TEMP fällst mir ein : das ist normalerweise kein freigegebenes Netzwerk Verzeichniss.

Gut, danke, mal schauen, ob ich das auf Array umbauen kann. - Es sind aber viele Sätze, so zwischen 15'000 und 40'000, wenn ich mich richtig erinnere (muss mal nachschauen).

mehr als 1.5 GB ? dann unter 64bit versuchen.

[brandelh]

Wenn du mehr als 20.000 Datensätze hast, kann das je nach Datenmenge je Eintrag zuviel werden und auch im RAM sehr langsam.
Auf jeden Fall sollte die temporäre Datei LOKAL liegen.

[brandelh]

Hast du den Key gesetzt ?
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lanmanworkstation\Parameters\DisableFlushOnCleanup = 1
der soll bei langsamem dbAppend() helfen, eventuell ja auch bei append from ...

[Daniel]

Hallo Hubert

Diesen Registry-Key habe ich, wie oben erwähnt, ja dem Netzwerk-Verantwortlichen gemeldet (mit dem KB8.... oben), und angeblich soll das alles durchgeführt worden sein. Aber ob es wirklich so ist, kann ich erst kontrollieren, wenn ich wieder mal dorthin reise ...

[brandelh]

Ich lese nun mit der Registry Klasse von Thomas Braun die Key im Programm aus (über INI gesteuert, damit ich es bei Problemen abschalten kann.).
Hierbei wollte ich eigentlich die Liste aller enthaltenen Keys/Variablen eines Keys abfragen :KeyList() und :ValueList() finden aber nichts.
Muss man da bei XP SP 3 ff. etwas ändern ?

Auf der Homepage gibt es keine neuere Version, hat jemand damit Erfahrung ?