APPEND im LAN verlangsamt

[Daniel]

Beim Kunden mit kleinen LAN (Win-Server 2008, 3 bis 5 Workstations XP oder Win7) gibt es störende Wartezeiten beim Append mit DBFNTX.
Im vorherigen LAN mit Novell und Win2K / XP waren keine Wartezeiten spürbar, mit der gleichen APPlikation mit XBase 1.90.331
Auf dem betreffenden DBF mit ca. 200'000 Records sind nur 2 NTX aktiv.

Könnte der Einsatz von ServiceLevel1 die Situation verbessern?
Oder hat das ev. mit SMB2 von Windows zu tun?

[georg]

Hallo, Daniel -


bezüglich Windows 2008 Server habe ich recht schlechte Erfahrungen bezüglich der Geschwindigkeit in meinem Heimnetz gemacht.

W2K8 -> Workstation, 50 MB - Dauer ca. 10 Minuten
Workstation -> W2K8, 48 MB - Dauer ca. 1 Minute

Recherche im Internet ergab, dass wohl viele Probleme mit W2K8 haben. Ich habe viele der Lösungsvorschläge ausprobiert, konnte aber keine Verbesserung feststellen. Inzwischen habe ich (erneuter Hinweis: Heimnetzwerk) ein NAS für diese Aufgaben eingesetzt, die Durchsatzwerte sind deutlich besser als früher.


Gruss,

Georg

[AUGE_OHR]

Beim Kunden mit kleinen LAN (Win-Server 2008, 3 bis 5 Workstations XP oder Win7) gibt es störende Wartezeiten beim Append mit DBFNTX.

wenn es sich nur um die Wartezeit handelt http://support.microsoft.com/kb/825433 oder hast du auch 8999 Errors ?

Im vorherigen LAN mit Novell und Win2K / XP waren keine Wartezeiten spürbar, mit der gleichen APPlikation mit XBase 1.90.331
Auf dem betreffenden DBF mit ca. 200'000 Records sind nur 2 NTX aktiv.

Tja Novell ist eben was anderes als W2K8

Könnte der Einsatz von ServiceLevel1 die Situation verbessern?

Nein

Oder hat das ev. mit SMB2 von Windows zu tun?

Ja

btw. XP "und" Win7 als Client am W2K8 Server ... da sind durch XP Problem vorprogrammiert.

[Daniel]

wenn es sich nur um die Wartezeit handelt http://support.microsoft.com/kb/825433 oder hast du auch 8999 Errors ?

Danke, Jimmy
Nein, keine 8999 Errors, meines Wissens. Habe KB 825433 nachgeschaut. Da heisst es aber, dass das Problem bereits mit XP SP2 korrigiert war - jetzt haben wir SP3 drauf ...
Dürfte demzufolge nicht mehr damit zusammenhängen (oder irre ich mich?).

Tja Novell ist eben was anderes als W2K8

Novell war was anderes - müsste man vielleicht sagen ...

btw. XP "und" Win7 als Client am W2K8 Server ... da sind durch XP Problem vorprogrammiert.

Und die Lösung? Überall Win7 draufmachen?

[Jan]

Und die Lösung? Überall Win7 draufmachen?

Einfach das Tool von der Alaska-Homepage runterladen (Hot News vom 17.12.2010), und auf dem Server laufen lassen. WENN daß das Problem war, dann ist das damit behoben. Ob nun XP- und Win7-Clients gemischt ist vollkommen egal.

Ich bin mir aber nicht sicher, ob SMB 2 wirklich das Problem darstellt.

Jan

[Daniel]

Hallo Georg

Danke. Ja, ich denke auch, dass ein NAS im Heimnetzwerk besser ist, v.a. auch einfacher.
Aber der Kunde braucht das LAN mit Server und allem drum+dran. Die erfassen Bestellungen auf 3 Workstations gleichzeitig, und mögen natürlich nicht dauernd warten, bis der W2K8 mit den WS die Kommunikationsprobleme geklärt hat

[Daniel]

Einfach das Tool von der Alaska-Homepage runterladen (Hot News vom 17.12.2010), und auf dem Server laufen lassen. WENN daß das Problem war, dann ist das damit behoben. Ob nun XP- und Win7-Clients gemischt ist vollkommen egal.
Ich bin mir aber nicht sicher, ob SMB 2 wirklich das Problem darstellt.
Jan

Den SMB2-Fix von Alaska haben wir gleich schon zum Anfang drauf gemacht.
Das sollte also auch nicht das Problem sein.

[AUGE_OHR]

Nein, keine 8999 Errors, meines Wissens.

keine 8999 ist schon mal gut

Habe KB 825433 nachgeschaut. Da heisst es aber, dass das Problem bereits mit XP SP2 korrigiert war - jetzt haben wir SP3 drauf ...
Dürfte demzufolge nicht mehr damit zusammenhängen (oder irre ich mich?).

interessant was du zu gelesen haben meinst ...

es ist wohl anzunehmen das im SP3 inzwischen eine "neuere" DLL Version vorliegt, aber wenn es nun "zusätzlich" die Bemerkung eines Registry Eingriff gibt dann gehören beide "zusammen".

Sie müssen auch hinzufügen und aktivieren den Registrierungsunterschlüssel
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lanmanworkstation\Parameters\DisableFlushOnCleanup

wenn nun in der Registry der Eintrag nicht existiert werden die default Werte genommen ... 1 oder 0 ?

ein Registry Eintrag bewirkt üblicherweise das überschreiben der default Werte und die Auswirkungen eine Änderung sollte man überprüfen.

Tja Novell ist eben was anderes als W2K8

Novell war was anderes - müsste man vielleicht sagen ...

als reiner File Server für Xbase ( alle Version ) ist eine v3.2x, aufgebohrte mit v4.x NLM, Promise IDE RAID, 7200 rpm und Gbit Netzwerkkarten, P4 3GHz (ohne HT), 1GB RAM noch immer ein Fels in der Brandung.

wenn man eine alten W2K3 Server hat und einen neuen W2K8 dann ist der NW Server in der "Mitte" wie eine Windows-Mauer ... aber per SPX Protokoll kommt man da durch

btw. XP "und" Win7 als Client am W2K8 Server ... da sind durch XP Problem vorprogrammiert.

Und die Lösung? Überall Win7 draufmachen?

YUP, das wäre optimal ... und alle "alten" Ops Lock Registry Hacks wieder auf "original" bringen.

Der "SMB2" Fix von Alaska enthält lediglich 3 Registry Einträge unter \Lanmanworkstation und sollte mit deinem APPEND ( auf dem Server ) weniger zu tun haben.

[Daniel]

Habe KB 825433 nachgeschaut. Da heisst es aber, dass das Problem bereits mit XP SP2 korrigiert war - jetzt haben wir SP3 drauf ... Dürfte demzufolge nicht mehr damit zusammenhängen (oder irre ich mich?).

interessant was du zu gelesen haben meinst ...
es ist wohl anzunehmen das im SP3 inzwischen eine "neuere" DLL Version vorliegt, aber wenn es nun "zusätzlich" die Bemerkung eines Registry Eingriff gibt dann gehören beide "zusammen".

Sie müssen auch hinzufügen und aktivieren den Registrierungsunterschlüssel
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lanmanworkstation\Parameters\DisableFlushOnCleanup

wenn nun in der Registry der Eintrag nicht existiert werden die default Werte genommen ... 1 oder 0 ?

ein Registry Eintrag bewirkt üblicherweise das überschreiben der default Werte und die Auswirkungen eine Änderung sollte man überprüfen.

Ok, da magst Du recht haben, danke für die Präzisierung!
Doch für mich zeigt es nur, dass die Info bei MS (wieder mal) nicht sehr klar ist, auch wenn ich die originale us-en-Version studiert habe http://support.microsoft.com/kb/825433?ln=en-us (in eine technische Uebersetzung habe ich wenig Vertrauen!).
Unter "Status" (nach all den Massnahmen zur Lösung, heisst es da:

Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section. This problem was first corrected in Microsoft Windows XP Service Pack 2.

Das verstehe ich so, dass das Problem mit XP-SP2 korrigiert war. Und nicht, dass ich es immer noch von Hand (oder via Hotfix) korrigieren muss. Oder wofür ist dann ein Service Pack da??

Wie soll man jetzt wissen, ob die Bemerkung des Registry-Eingriffs "zusätzlich" war?
Aber gut, Kontrolle ist immer besser da hast du natürlich nochmal recht.

[Daniel]

- Die Registry konnte ich noch nciht checken - muss erst mal zum Kunden hinfahren. Da werd ich ein Testprg machen um zu schauen, was da abgeht.

Was meint Ihr - könnte ADS Advantage Database die Performance verbessern?

Wie gross wäre der Aufwand zum Anpassen?

[UliTs]

Hallo Daniel,

greift nur Dein eigenes Programm auf die DBF-Tabellen zu?
Dann wird der Aufwand bei Einsatz der AdsDbe von Alaska wahrscheinlich minimal sein. Die AdsDbe ist in der Professional-Subscription von Alaska enthalten.
Im optimalen Fall musst Du nur statt der DbfNtx die AdsDbe benutzen und eventuell den Verbindungsaufbau anpassen (<1 Stunde Aufwand).
Wenn Du in den Indizes User Defined Functions einsetzt, müssen auch die Indexdateien angepaßt werden.
Mehr fällt mir auf Anhieb nicht ein.
Ach ja, natürlich muß auch der Ads installiert werden (unter Windows schnell erledigt).
Als Test kann man auch eine Ads-Enwicklerversion (kostenlos) auf dem eigenen Entwicklungs-Rechner installieren.
-
Auch ohne weitere Programmänderungen müssten umfangreiche Datenbankanwendungen wesentlich schneller laufen, als bisher.
-
Wenn Filter eingesetzt werden, kann man diese mit geringem Aufwand drastisch optimieren .

Viele Grüße

Uli

[ramses]

Hi

ADS Advantage Database steigert die Performance BETRÄCHTLICH!!!!!
Un beseitigt auch die 8999 und anderen Probleme und Fehler beim Datei Zugriff.

Dazu ist aber das Servermodul nötig das du kaufen musst. Damit ist ein
Client-Serverbetrieb möglich in welchen nur noch das Servermodul auf die
Datei zugreift, alle Clientzugriffe laufen über Anweisungen über einen TCP Port.

Eine weitere Alternative ist den Server unter VMWare aufzusetzten und darin
Win2008 für Alltägliches und einen Novell für Betriebliche APP aufzusetzten.
So kannst du auch im Jahr 2012 die super Performance von Novell nutzen ohne
als veraltet oder rückständig zu gelten.

Ich hab das schon einige Male so gemacht und auf diesen System nie irgendwelche
Probleme, nicht mal SMB2 muss berücksichtigt werden.

Cu Carlo

[Daniel]

Danke, Uli

Ja, es greifen nur meine eigenen Apps auf die DBF zu.
In den Indizes setze ich keine UDF's ein.

Dann werde ich mittelfristig eine solche Variante ins Auge fassen und das mal testen.
Aber dazu müsste ich erst mal meine Subscription upgraden.

Jetzt muss ich aber erst mal ein Testprog schreiben, um den APPEND im LAN zwischen XP und dem W2K8 zu testen.

[AUGE_OHR]

Jetzt muss ich aber erst mal ein Testprog schreiben, um den APPEND im LAN zwischen XP und dem W2K8 zu testen.

schau dir mal das AD8999.ZIP im Thread http://www.xbaseforum.de/viewtopic.php? ... mb2#p62530 an

[Daniel]

Thx, Jimmy

werde ich nächstens mal durchschauen und testen.

Gut, habe ich in einem andern Thread ("NAS Geschwindigkeit...") gesehen, dass man auch ein kleines Haus-Network mit NAS zum Testen nutzen kann. Auch wenn mein Buffalo-NAS nicht das Gleiche ist wie ein fetter W3K8 Server.

[Werner_Bayern]

Einfach das Tool von der Alaska-Homepage runterladen (Hot News vom 17.12.2010), und auf dem Server laufen lassen. Jan

Bin gerade auf diesen Beitrag gestoßen, auf der Alaska HP steht jedoch:

This MSI package needs to be executed on any Vista and Windows 7 workstation in a network

Nicht am Server!?

[Markus Walter]

Hallo Werner,

die Registry-Einstellungen die durch das MSI gesetzt werden (FileInfoCacheLifetime, FileNotFoundCacheLifetime, DirectoryCacheLifetime) betreffen den Workstation-Teil. Sie haben nur Auswirkungen am Client. Das Einspielen am Server ist unnötig (es sei denn, dieser greift selbst wieder als Client auf einen anderen Server zu, z. B. TS mit Datenablage auf einem FileServer).

Die Schalter beeinflussen das Caching-Verhalten der Workstation (sprich den Zeitrahmen, welcher der Client sich genehmigt, bis er wieder den Server fragt, wie es denn nun wirklich aussieht...)

[Werner_Bayern]

Ok danke, dann ist das ja klar gestellt, dass Jan sich da vertan hat mit der Aussage, das Tool am Server laufen zu lassen.
Also grundsätzlich das Tool an den Arbeitsplätzen und am Server wenn dann nur:

Code: Alles auswählen

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters]
"EnableOplocks"="0"

[Daniel]

Update:
Also inzwischen konnte die Geschwindigkeit des APPEND resp. DbAppend durch den Einsatz eines Gigabit-Switch gesteigert werden.
Es handelt sich um ein kleineres Network mit Windows Server 2008 und WindowsXP-Workstations gemischt mit Windows7-Workstations.

Allerdings sind jetzt neue Probleme aufgetaucht, diesmal bei APPEND FROM für eine temp. Report-DB.

Das werde ich aber in einen neuen Thread stellen.