Netzwerkperformance

[Tom]

Hallo.

Zwei Anwender klagen darüber, daß unser Programm deutlich langsamer reagieren würde, sobald mehr als ein Arbeitsplatz im Netz aktiv ist. Die üblichen Verdächtigen:

Virenscanner prüft alle Dateien beim Öffnen
Switch, Hub, Verkabelung, Netzwerkkarte
Opportunistisches Locking

sind auszuschließen. Das Netz ist homogen, XP auf den Arbeitsplätzen und 2K auf dem Server. Ich bin ein bißchen ratlos - hat noch jemand einen Tip, wonach man schauen könnte? 1.9 mit DBFNTX und Extended Locking, keine ADS in diesem Fall.

[Jan]

Tom,

eher unwahrscheinlich, aber: Kennst Du deren Netzwerkprotokoll? Ich habe auch schon mal in Windows-Netzen Situationen Peer-to-Peer erlebt, und da kann man mit mehreren Personen wirklich nicht mehr Performant arbeiten.

Jan

[Tom]

Hallo, Jan.

Das ist es sicher nicht, trotzdem danke für den Hinweis.

Im Moment forschen wir in Richtung QoS (Quality of Service).

[andreas]

Hallo Tom,

ich hatte das gleiche Problem bei einem Kunden, aber mit FOXCDX-Dateien. Nach dem Ich Filter auf Scope umgestellt habe, funktioniert es.

[Martin Altmann]

Hallo Tom,
ich habe kein verteiltes Programm - bei mir arbeitet ja jeder lokal (zum Glück).
Aber: Um welche Datenbank geht es denn - generell oder nur bei bestimmten?
Wie groß sind die Datenbanken?
Wie sehen die Rechte auf dem Server aus - wird im Security-Log alles (jeder Zugriff) mitprotokolliert?
Und warum ist die Hardware definitiv als Verursacher auszuschließen? Das wäre nicht das erste Mal (s. Newsgroups), dass eine fehlerhafte Netzwerkkarte zu Einbußen führt (muss bei anderen Programmen nicht unbedingt diese Auswirkungen zeigen)...
Und wie sind die Netzwerkkarten konfiguriert? Stehen alle (XP und 2K) auf 100MBit? Oder steht wenigstens eine auf AutoSelect (unbedingt ändern!!) oder weicht sonst von den anderen ab?
Viele Grüße,
Martin

[Schubi]

Hallo Tom,

ist auf dem Server Windows Server 2003?

Dann sieh mal in der Registry nach, ob folgende Werte gesetzt sind.
Bei meinen Kunden hat das Einspielen dieser Reg-Datei meistens Erfolg gehabt.

Code: Alles auswählen

REGEDIT4
; NTServer.REG    Created & maintained by Nick Ramsay <reghack@witzendcs.co.uk>
; Available from: http://www.witzendcs.co.uk/html/nt_networking.html
; Last edit:      16 October 2005 21:41
; This file will alter the behaviour of the network redirector on 
; Windows NT, 2000/2003 & XP servers & workstations acting as servers

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters]
; Prevent premature workstation disconnection - default is 0000000f (15 minutes)
"autodisconnect"              =  dword:ffffffff
; This one is for Server 2003 - default is 2 minutes!
"ConnectionNoSessionsTimeout" = dword:ffffffff

; Forces the server to really close a file when instructed
"CachedOpenLimit"= dword:00000000

; The following 2 entries force oplocks off
"EnableOpLockForceClose" = dword:00000001
"EnableOpLocks"          = dword:00000000

; The following 2 entries force the server to immediately report a sharing violation
; Although this looks wrong, it is actually the best option for Clipper
"SharingViolationDelay"   = dword:00000000
"SharingViolationRetries" = dword:00000000

; This one is for Win2K and later
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MRXSmb\Parameters]
"OplocksDisabled" = dword:00000001

[Tom]

Hallo, Ihr.

Herzlichen Dank. Wir prüfen u.a. die hier gemachten Vorschläge und ich gebe Laut, ob irgendwas davon Erfolge erzeugt hat.

[brandelh]

Hi,

nachdem solche Themen ja immer wieder auf kommen würde mich interessieren,
ob ihr damals euer Problem lösen konntet.

[Rudolf]

Hallo,
habe auch grosse Probleme bei manchen Kunden, einen habe ich sogar durch das Problem verloren. War nicht zu lokalisieren, die Zusammenhänge waren total eigenartig und für mich nicht logisch. Interessanterweise habe ich Kunden mit eher heimwerkermäßig zusammengebauten Netzwerken, bei denen alles super schnell läuft. Andere haben einen teuren Server mit super Performance, aber wenn 2 User gleichzeitig die selbe Datenbank benutzt haben, ist das System total langsam. Wenn ich vom selben Arbeitsplatz die Datenbank 2 mal aufgemacht habe (Applikation zwei mal gestartet) ist die Geschwindigkeit ok. Habe alle Einstellungen am Server und Client die hier und anderswo gepostet wurden probiert, kein Erfolg. Es waren auch total gleich konfigurierte Arbeitsplatzrechner, mit völlig unterschiedlicher Geschwindigkeit im XBase++. Das Netzwerk wurde mehrmals von Profis komplett durchgecheckt, aber kein Fehler im Netz.
Bin nicht der Einzige mit diesem Problem, es haben sich auch noch andere gemeldet. Meines Wissens hat bis jetzt noch niemand das Problem gelöst.
Grüsse
Rudolf

[AUGE_OHR]

hi,

Meines Wissens hat bis jetzt noch niemand das Problem gelöst.

Ich habe noch jedes Netzwerk zu laufen bekommen, nur manchmal muss man eben "radikal" sein.
Das man nach der Änderung von Registry Settings neu booten muss ist ja wohl klar und das
heisst beim Server : Netzwerk runterfahren ... und das nach JEDER Änderung ... bedenkt man
nun die Kombination´s Möglichkeiten sollte man für eine solche Aktion durchaus mal 1 ganzes
Wochenende einplanen ...

Das andere ist "die" Station ... blabla ... sowas wird bei mir erstmal gegen andere Hardware
ausgetauscht ... evtl. reicht es 2 Station zu vertauschen um zu sehen was passiert.

Tja und dann die Test Programme ... die "normal" Application ist dafür meisten nicht zu
gebrauchen da die ja User Aktionen erfordert ... also "spezielle" Testprogramme schreiben welche
die verschiedenen Aktionen wie APPEND, DELETE und natürlich die Lock Functionen wobei man
bei "gemischter" Hardware mittels DBInfo() die DELAY / RETRY Werte "anpassen" muss.

Wenn man das alles gemacht hat und evtl. auch noch ein "Gegentest" mit einem "frisch
installierten" Server gemacht hat, DANN kann man behaupten man hätte alles "Menschen
mögliche" getan ... in paar Minuten bekommen man so ein "Problem" nicht raus !!!

[AUGE_OHR]

hi,

hier noch mal paar Tips :
Workstation :
a.) auf allen Stationen exakt die selben OP´s Lock Einträge
b.) Bei den Workstation die SERVER Dienste abschalten
c.) möglich nur ein Netzwerk Protokoll benutzen
d.) bei TCP/IP die "Blöck" Grösse überprüfen ... evtl. wurden die "für" Internet optimiert
e.) evtl. auch mal "Extendet Locking" abschalten
f.) mit DBINFO und den DELAY/RETRY Werten rumspielen

Server :
a.) alle Dienste die nicht unbedingt benötigt werden abschalten
b.) zu testen immer einen "freien" Server benutzen d.h. es sollte nichts ausser dem M$ Server
laufen ... auch keine Funkuhr oder Backup Programme oder sonstige "Dienste"
c.) alle Workstationen runterfahren bevor man den Server neu bootet
d.) nach jeder Änderrung den Server 2x (!!!) booten
e.) bei mehreren Netzwerk Karten immer nur eine testen (auch wenn man dazu die anderen
Netzwerk Karten ausbauen muss.
f.) von Internet Router "trennen"

sicherlich gibt es noch mehr Punkte die man beachten sollte (Kommentare und Ergänzungen
erbeten). Das ganze gibt für M$ Netzwerke. Bei NW Netzwerk muss man "nur" den richtigen
Client > 4.83sp3 benutzen und bei IP/IPX das "richtige" Protokoll einstellen.

so und nun muss ich mich um eine Workstation kümmern die heute versagt haben soll ... aber ein
2nd PC hab ich schon "daneben" stehen (der "alte" PC) ... "die" neue Kiste "kenne" ich schon das
die des öfteren "versagt" ... der Headspreader von der Northbridge wird bei der Baureihe mit
"Ösen" und Klammeren befestigt und die "ziehen" gerne die "Ösen" aus dem Mainboard ...

[AUGE_OHR]

hi,

so und nun muss ich mich um eine Workstation kümmern die heute versagt haben soll ...

hm ... toll, obwohl er ja nicht funktionieren soll wurde der PC nicht ausgeschaltet ...
tja und was soll ich sagen ... angeschlossen, hochgefahren und ? ... doch ich habe ein "Problem",
den die MAUS funktioniert nicht ... keine MAUS vorhanden in der System Steuerung ... hm ...

soweit zum Thema USER.

[Rudolf]

Hallo Jimmy,
natürlich hab ich die alles ausprobiert, und das mehrmals und auch bei anderen Servern und Workstations, und das im Beisein von Netzwerkprofis. Ändert nichts dran, dass es defintiv Betriebszustände gibt, bei denen es in XBase++ zu extremen Geschwindigkeitseinbussen beim Datenbankzugriff kommt, welche bis jetzt nicht gefunden wurden.
Grüsse
Rudolf

[hschmidt]

Hallo Rudolf,

hast du es schon mal mit ADS versucht?
Damit hast du die Möglichkeit, mit geringsten Codeänderungen ein echtes Client-Server-Datenbanksystem einzusetzen, bei dem du dich um OP-Locks und diesen ganzen Kram überhaupt nicht kümmern mußt.
Wir machen grundsätzlich keine Netzwerkinstallation ohne den ADS-Server, und bei Einzelplatzinstallationen der Localserver ist sogar kostenlos.

Hans

[AUGE_OHR]

hi,

natürlich hab ich die alles ausprobiert, und das mehrmals und auch bei anderen Servern und Workstations, und das im Beisein von Netzwerkprofis.

Reden wir von W2K Sp4 und W2003 R8 als dedizierte Servern ?

Waren die Netzwerk "Profis" MSCN Leute ? Solche Leute, Bekannte von mir, hab ich mal an
meinen Server gelassen ... gut das ich vorher ein Image gemacht hatte. Alle M$ Produkte liefen
prima aber Xbase++ lief dann "gar nicht mehr" ...

... und dann wären da noch die M$ Updates ... nach jedem Update sollte man die Registry Werte
überprüfen was dann drin steht und was geändert wurde ...

Ändert nichts dran, dass es defintiv Betriebszustände gibt, bei denen es in XBase++ zu extremen Geschwindigkeitseinbussen beim Datenbankzugriff kommt, welche bis jetzt nicht gefunden wurden.

Dann schicke doch mal dein Sample zu Alaska wenn sich der "BUG" reproduzieren lässt.

Klar könnte ich noch tausend Gründe aufzählen bei denen solche Effekte auftreten, aber all die
haben nichts mit Xbase++ zu tun ... da würde sich Cl*pper genau so verhalten ... ( Ich meine
jetzt nicht SET FILTER im Browse oder so ...sowas macht doch keiner mehr heutzutage ...)

Da fällt mir gerade ein : Hab ich davon erzählt das ich am Anfang mit W2003 R2 die Lizence von
5 auf 10 gestellt hatte ? Unter W2K "kann" man das ja machen ohne Nebeneffekt,aber der W2003
hat dann beim 5th User auf einmal "Probleme" gemacht und war irre langsam. Ich habe dann 3
Tage danach gesucht bis ich auf die Idee kam die gekauften Zusatz CAL zu installieren ... tja
der W2003 hat es wohl "gemerkt" das es nur eine 5ver Version war ...

Du verwendest du keine eigene DBESYS, oder ? Das wundert mich sehr den gerade damit kann
man das DELAY/ RETRY Verhalten massgeblich beeinflussen was bei "gemischten" PC ein MUSS
ist. Hier wird der von dir beschriebene Effekt sehr deutlich wenn z.b. ein 3GHz gegen eine 2GHz
läuft ... der 3GHz "blockiert" praktisch den 2GHz PC im Netzwerk. Mit der "richtigen" DBESYS
Einstellung laufen nun die 2GHz PC "schneller" im Netzwerk als der 3GHz z.b. bei Browse ... nur
beim Indezieren ist der 3GHz dann immer noch schneller ...

Es gibt also "tausend" Schrauben an denen man "drehen" kann ... ausprobieren. Ich habe übrigens
damals über 1 Monat gebraucht bis ich den W2003 Server auf "Novell" Niveau gebracht hatte ...
jeden Tag das Logbuch ausgelesen, gegooglet , ausprobiert und dann Testläufe mit mindestens
3 Stationen gleichzeitig gemacht ... nur läuft er die Woche, aber am Sonntag braucht er "Pflege"
und wird neu gebootet sonst wird er nach ca. 17-18 Tagen "langsam" ... und ich weiss nicht
warum.

[Jan]

Ich misch mich hier jetzt mal "unproduktiv" ein.

Die Frage ist doch, woran das liegt. Ist das
- ein Problem von Windows oder dem Netzwerk,
- oder ist das ein Problem von Xbase++ generell,
- oder ein Problem in der Programmierung?

Wenn alle anderen Programme sauber laufen, dann ist das vermutlich eher nicht ein Problem von Windows oder dem Netzwerk.

Wenn das Programm sauber läuft, aber in machen Umgebungen nicht, dann ist das vemutlich eher nicht ein Problem der Programmierung.

Bleibt noch Xbase++. Warum sollte das in einigen Umgebungen sauber laufen, und in anderen nicht? Ich selber habe jedenfalls das Phänomen gehabt (hab das hier auch gepostet, ohne zu einem Resultat zu kommen), daß Browses ewig lange gebraucht haben, um dargestellt zu werden. Auf einem einzigen Rechner in unserem gesamten Netzwerk. Lag also wohl an dem Rechner. Aber alle anderen Programme liefen ohne Probleme darauf, nur dieses eine Xbase++-Programm mit seinen Browses nicht. ???

Und die Lösungsvorschläge von Jimmy sind zwar ganz nützlich, können aber wohl nicht der Weisheit letzter Schluß sein. Was denkt der der Kunde wenn er das Programm auspackt und erstmal 10 Seiten Handbuch lesen muß mit: Unter Windows diese Version bitte diese und jene Registrywerte umsetzen, bei der anderen Version aber bitte diese anderen, und auf dem Server noch dieses und das umstellen. Aber nur wenn der Server Windows Windows ist. Unter Linux bitte diese und und jene Werte umstellen, und unter Novell natürlich noch ganz andere. Der hält uns doch für bekloppt! Denn andere Programme laufen schließlich auch (ich rede jetzt nicht von OPLocks, wobei auch da manche Leute keinerlei Verständnis für haben).

Nur mal so meine Gedanken dazu.

Jan

[Manfred]

Hi Jan,

sicherlich nachvollziehbar, was DU meinst. Aber ich denke einmal Jimmy liegt nicht so verkehrt. Es sind halt 1000 Schrauben, an denen man drehen kann und ab und zu auch drehen muß. Ich habe es bei mir auf Linux/Samba laufen und bin zufrieden. Ein Kunde hat die gleiche Konfiguration und schnellere Hardware als Server, aber das Netzwerk ist langsamer als bei mir. Manchmal stimmt die Werbung der Industrie halt nicht, wenn sie behauptet alles ist easy und geht wie von selbst....
Allerdings kann man natürlich unter Samba in der Text Config wesentlich leichter erkennen, was wie wo geschraubt wurde. (Meine Meinung)

[AUGE_OHR]

hi,

Was denkt der der Kunde wenn er das Programm auspackt und erstmal 10 Seiten Handbuch lesen
muß mit:

unabhängig davon das man immer vorher das Handbuch lesen sollte hab ich das Problem "so" nicht
den ich liefere nicht an "End-Kunden" sondern gebe ja meinen Source ab.

Alles andere nenne ich Service, den ich "vor Ort" vornehme wenn ich den Kunden besuche um zu
sehen was es neues gibt (Aufträge holen) und ob er neue Hardware hat. Inzwischen habe ich die
meisten Kunden soweit das die sich "freiwillig" bei mir melden und mir von ihren Plänen erzählen
bevor die loslaufen und einkaufen oder mir eins der neuen Geräte zur Verfügung stellen damit ich
die Maschine "kennen lerne" und dann bei Problemen ihnen helfen kann. Auch wissen die
inzwischen das wenn "eine" Maschine spinnt und alle anderen laufen, das sie mich gar nicht damit
"belästigen" müssen den von mir kommt dann nur die Antwort "kauf doch eine neue", es läuft
doch auf allen anderen PC´s und für die Hardware ist mein Bruder zuständig.

Ich kann nur wiederholen das M$ Netzwerke "viel Pflege" benötigen wenn man darauf Xbase++
laufen lassen will und das man auch den Server "öfter" neu booten sollte ... bei Novell hat man
damals 1 mal im Jahr ein neuen Patch eingespielt und das war´s ... und er läuft noch immer ...

Also denke ich das es an M$ liegt, den auch die Op´s Lock sind ja "für" M$ Produkte gedacht wie
Office 2007 wo ich schon wieder neue Einträge gefunden habe die ich googlen muss wozu die
gedacht sind, welchen Neben Effect die haben könnten und wie sich das auf Xbase++ auswirkt.
(ich habe noch die 2003 XP Version)
Es bringt also gar nicht wenn man "nur" alle Registry Settings setzt, man muss die "richtigen"
setzten was wiederum von den verwendeten Anwendungen abhängig ist.

Frage : ist "euch" den überhaupt klar warum sich Xbase++ so verhält ?

[Manfred]

Nö Jimmy, dann rück mal raus mit Deinem Wissen. Warum verhält sich Xbase++ so?

Von Windows NT Servern weiß ich noch, diese Server min. 1x im Monat neu zu booten, weil die sich zugefahren haben. Tja, aber der Kunde scheint so Systeme wohl haben zu wollen......
Irgendwo wird immer ein Masochist morgens wach, man muß ihn nur finden...

[Jan]

Hallo Manfred und Jimmy,

vielleicht habt Ihr mich falsch verstanden.

Mir ist klar, daß ein Server Wartung braucht. Was natürlich gerne vernachlässigt wird. Frei nach dem Motto: Rechner auspacken, hinstellen, anmachen, läuft perfekt. Ist aber eben gerade nicht so.

Wobei mir MS-Server auch gegen den Strich gehen. Unseren mussten wir mind. 1 x jeden Monat neu starten. Unsere gesammelten Linux-Server laufen mind. 1 Jahr ohne Neustart.

Das Problem liegt aber dadrin: Beim Kunden laufen ja schon diverse Perogramme. Office, Buchhaltung, Internet, etc. Alles läuft nach mehr oder weniger Einstellerei sauber. Dann kommen wir, und schon haben wir das Problem. DAS war das,was ich meinte. Das Netzwerk läuft stabil, aber unser Xbase++-Programm hakt irgendwo. Und dann kommt Jimmys in mühsamer Kleinarbeit zusammengestelltes 10seitiges Handbuch zum Tragen. Clients neu konfiguruieren, Sever umstellen. Und der Kunde fragt sich, was das soll, der Rest lief doch auch.

Deswegen hatte ich auch das Beispiel mit den Browses gebracht, obwohl das nicht zur Netzwerk-Performance gehört. Weil das Programm überall lief, nur auf dem einen Rechner nicht. Auf dem aber ansonsten alle anderen Programme liefen. Das war also kein Windows-Problem, aber auch kein Programmierproblem. Was bleibt übrig? Womit ich Alaska hier keineswegs schlecht machen möchte. Datenbankanwendungen sind in manchen Bereichen eben "empfindlicher" als z. B. ein stinknormales MS Word oder etwas anderes in der Richtung.

Jan

[AUGE_OHR]

hi

Nö Jimmy, dann rück mal raus mit Deinem Wissen. Warum verhält sich Xbase++ so?

Tja weil es ja nicht im Handbuch oder sonst wo steht denke ich das es viele nicht wissen, so wie
ich 2002 als ich die v1.2 (oder war es schon die v1.3) hatte. Während es "local" ja ging hatte
ich im Netzwerk (Novell v3.21) immer den GenCode 40 ... ob bei einem SEEK() oder einem GOTO()
und teilweise sogar bei einem SKIP. Der Code war damals noch mit für Cl*pper ausgelegt und der
lief nun einwandfrei. In meine "Not" habe ich mich dann für die Devcon in NH angemeldet in der
Hoffung jemanden von Alaska zu erwischen wegen des Problems. Ich habe es dann geschafft
Steffen während einer Raucher Pause anzusprechen und er fing an von OP´s Lock zu erzählen.

Warum aber das ganze und was ist der Unterschied zu Cl*pper, war meine Frage den die Fehler
schienen mir ja nichts mit RLOCK() tu tun zu haben ...

Mit der Antwort will ich nun noch etwas warten, ob sich vielleicht noch jemand meldet der es
weiss. Übigens das "Paper" über Op´s Lock kam 1 Woche nach der Devcon raus was mich
wunderte den Steffen hat sich ganz schön "gewehrt" es anderen Xbase++ User "offizell"
mitzuteilen ... ich sehe heute noch sein Grinsen und dachte mir ...

[Tom]

Hallo, Rudolf.

Welche DBE ist bei Dir im Einsatz? DBFNTX unterstützt seit einem der letzten Hotfixes oder (genau memoriere ich das nicht) seit der 1.9 "Extended Locking" bei Indexen, was zumindest bei uns sehr deutliche Performanceverbesserungen gebracht hat (DBFCDX unterstützt es schon länger). Im Gegensatz zum "handelsüblichen" Index-Locking, das die Indexdatei nicht nur bei Schreib-, sondern auch bei allen (!) Leseoperationen komplett sperrt - zwar nur für Millisekunden, aber eben vollständig und bei jedem Zugriff - sorgt Extended Locking für eine Sperrung auf Datensatzebene. Es lässt sich einfach dieserart aktivieren:

Code: Alles auswählen

DbeInfo(COMPONENT_ORDER,DBE_LOCKMODE,LOCKING_EXTENDED)

Einfach mal ausprobieren*.

Am Rande bemerkt: OpLocking bzw. das Abschalten desselben "verkauft" Alaska seit der DevCon 2001 als eine Art Allheilmittel bei Performance- und Konsistenzproblemen in Windows-Netzwerken (also solchen mit Windows-Servern, wobei es auch bei Linux-Servern mit Samba standardmäßig aktiviert ist). Nach unseren Beobachtungen bringen die Einstellungen kaum etwas. Dramatische Performanceverbesserungen sind noch bei keinem Kunden aufgetreten.

(* aber nicht, wenn andere Anwendungen, die das nicht unterstützen, parallel auf diese Daten zugreifen!)

[Tom]

Ergänzung: Virenscanner haben sich immer wieder als besondere Performancebremsen erwiesen. Standardmäßig installieren sich fast alle aktuellen Virenscanner mit der Option, alle Dateien beim Zugriff zu scannen, also auch Tabellen beim Öffnen und Schreiben. Das kann bei auf Servern installierten Scannern zu Kaskadeneffekten führen, die letztlich einen Absturz bewirken können (Timeout bei Öffnungsoperationen), wenigstens aber zu deutlichen Performanceeinbußen. Vor allem dann, wenn in der Anwendung sehr häufig Dateien geöffnet werden. Es ist jedem Kunden anzuraten, Datenbankverzeichnisse bei diesem Scan-on-Open auszublenden oder diese - in etwas besser abgesicherten Netzwerken ohnehin überflüssige - Variante völlig abzuschalten.

[AUGE_OHR]

hi,

Weil das Programm überall lief, nur auf dem einen Rechner nicht. Auf dem aber ansonsten alle anderen Programme liefen. Das war also kein Windows-Problem, aber auch kein Programmierproblem. Was bleibt übrig? Womit ich Alaska hier keineswegs schlecht machen möchte. Datenbankanwendungen sind in manchen Bereichen eben "empfindlicher" als z. B. ein stinknormales MS Word oder etwas anderes in der Richtung.

sorry aber genau das ist doch ein solcher "Problem" PC !!! Wenn es sonst überall läuft und auf
dem nicht dann liegt es doch nicht an der Xbase++ Application "selbst" sondern an der
"Umgebung" in der es laufen soll. Ist auf dem PC M§ Office installiert ? Ich könnte wetten, das
wenn du den "platt" machst und sauber neu das OS() installierst, dass es dann funktioniert auch
dein Browse.

Aber nur wenn der Server Windows Windows ist. Unter Linux bitte diese und und jene Werte umstellen, und unter Novell natürlich noch ganz andere.

sorry auch das sehe ich anders den dafür hat man "früher" einen Netzwerk Spezialisten geholt
der z.b. eine Novell Patch eingespielt hat. "früher" hat kaum einer am Server rumgefummelt und
zu installieren gab es nichts. Auch für Cl*pper ist es notwendig am Novell Server Einstellungen
vorzunehmen (Turbo-FAT Problem) nur das es eben "einmalig" war und von Spezialisten gemacht
wurde.
Mit der "Update" Funktion von M$ haben wir doch schon etliche Patches gehabt die z.T. die PC´s
"totgemacht" haben ... und da gab es doch auch mal einen M$ Patch wo die Tastatur von
Xbase++ nicht mehr reagierte aber Office lief ohne Probleme?

Wenn ich also tatsächlich mal eine 10 Seiten Anweisung bekomme mit Informationen, was ja
"aussergewöhnlich" ist, dann ist das doch ein Grund es zu lesen weil es wichtig ist für den der
es installieren soll. Von einem "User" erwarte ich sowas natürlich nicht ... der macht ja auch
kein Backup vor einer Installation.

Die "Einstellungen" selbst übernimmt natürlich das Setup Programm welche meine Tools aktiviert,
aber das "überprüfen" der "Einstellungen" nach jedem Update ist genauso wichtig und sowas
nenne ich dann Service beim Kunden. Sollte ich nun eines Tage dazu nicht mehr in der Lage sein,
so wird sich wohl jemand anderes darum kümmern. Der ist dann heilfroh wenn er die 10 Seiten
Anleitung hätte.

[AUGE_OHR]

hi,

Am Rande bemerkt: OpLocking bzw. das Abschalten desselben "verkauft" Alaska seit der DevCon 2001 als eine Art Allheilmittel bei Performance- und Konsistenzproblemen in Windows-Netzwerken (also solchen mit Windows-Servern, wobei es auch bei Linux-Servern mit Samba standardmäßig aktiviert ist).

dazu muss man vielleicht noch sagen das vorher die Werte für DELAY bei 1000 lage und ab der
v1.8x auf 100000 erhöht wurde. Leider hat Alaska bei der Gelegenheit den RETRY Wert nicht an
die "schnelleren" PC´s angepasst den 15 (milisekunden) ist gut für eine 2GHz PC aber viel zu
wenig für ein DualCore ... und da haben wir wieder 2 Schrauben an denen man "gleichzeitig"
drehen muss. (höhere RETRY -> niedrigeres DELAY)

Nach unseren Beobachtungen bringen die Einstellungen kaum etwas. Dramatische Performanceverbesserungen sind noch bei keinem Kunden aufgetreten.

wieso denken alle Leute das es "mehr" Performance bringt ? Das Gegenteil ist der Fall,
es wird langsamer ABER sicherer und keine GenCode 40 mehr. (so MIRROR unter Novell auf 386 ?)

Im Gegensatz zum "handelsüblichen" Index-Locking, das die Indexdatei nicht nur bei Schreib-, sondern auch bei allen (!) Leseoperationen komplett sperrt - zwar nur für Millisekunden, aber eben vollständig und bei jedem Zugriff

und damit hast du auch schon einen Teil der Lösung verraten ... es wird bei Xbase++ "jede"
INDEX Bewegung gesperrt und nicht wie man glaubt bei GenCode 40 das die DBF gemeint sei.

Erst mit Extended Locking wurde das Timeing überarbeitet, aber den selben Effekt kann man
eben auch in der DBESYS erzeugen. Der Vorteil der DBESYS ist nun das ich ihm "meine Logic"
beibringen kann sodas er einen P3 gegenüber einem P4 anders behandelt. Das ist bei "alter"
Hardware notwendig den da macht nun das Extended Locking wiederum Probleme (P2 400MHz)

... mal sehen wie wir über das Thema denken wenn wir ARTIKA bekommen und wir zurück denken
wie "einfach" es doch früher war ...