Foxpro im Netzwerk ungeeignet?
werner meyer
mich verwundert etwas dass ich auf meine Frage bzw. Problem vom
14.1.2008 (Geschwindigkeit im Netzwerk) noch kein Beiträge vorhanden sind.
Ist denn Foxpro im Netzwerk ungeeignet?
Setzt denn sonst Foxpro niemand im Netzwerk ein?
(kann ich mir kaum vorstellen)
oder haben die Experten das sinkende Schiff bereits verlassen?
Ich war eigentlich bisher mit Foxpro soweit noch zufrieden.
Wenn es aber bereits bei zwei Benutzern im Netzwerk Probleme mit der
Geschwindigkeit gibt halte ich das für bedenklich.
Michael Bickel
nein, manche sitzen gerne auf dem sinkenden Schiff und warten auf das
Rettungsboot, das vielleicht ja auch dann tatsächlich kommen wird und
einem vor der VB/C .NET Krakenfamilie rettet.
Über Lan via Steckdose kann ich nichts sagen. Galt das nicht mal als
störanfällig?
Generell haben wir aber eigentlich keine Probleme im Netzwerk mit der
Geschwindigkeit. Das geht eigentlich recht zügig, mitunter natürlich in
Abhängigkeit, was sonst so passiert.
Ich habe gerade eine Datenbank mit 25000 Daten für einen Kunden
getestet, auch alles immer noch sehr flott. Insbesondere die Daten an
sich waren sehr flott da.
Als Buffermode wird meißt 2 verwendet, sowie Private Datasessions...
(in den Forms)
I.d.R., natürlich alles in Abhängigkeit vom Einsatzzweck.
Also, wenn man so will, ganz normale Einstellungen.
Viele Grüße
Michael
werner meyer wrote:
--
Jürgen Wondzinski
Keine Ahnung, was da bei dir los ist. Natürlich ist VFP fürs Netzwerk
geeignet, und es ist in dem Bereich der File-basierten Datenbanken noch
immer das Schnellste in der PC-Welt. Nur darf man einfach nicht vergessen,
dass die Zugriffsgeschwindigkeiten eines Netzwerks immer noch deutlich uter
denen einer lokalen Festplatte liegen, speziell wenn auch noch
Multiuser-Einsatz dazukommt. Beim lokalen Zugriff kann bei den heutigen
Hauptspeichergrössen locker die gesamte Datenbank im RAM gecached werden,
was bei Multiuser und Netzwerk halt einfach nicht geht, und dann regieren
wieder die realen technischen Gegebenheiten.
Hast du denn mal bei deinem Steckdosen-Netzwerk den realen Durchsatz
gemessen? (z.B. indem du mal eine grosse Datei kopierst und dabei die Zeit
misst)
Dein "Geschwindigkeitseinbruch" ist schlicht die _Normalität_ für jedwede
Netzwerk-Applikation, denn sobald im Multiuser-Betrieb gearbeitet werden
muss, ist nix mehr mit Caching, da muss jeder Datensatz aktuell geladen
werden.
Das "Opprtunistic Locking" macht nix anderes, als Netzwerkdaten lokal zu
cachen, solange der Server sagt, dass nur ein User drauf ist. Sobald ein
zweiter User die Datei aufmacht, wird das Client-Caching abgeschaltet. Durch
das Setzen der Registry-Keys wird auch im Einzelbenutzer-Modus nicht mehr
gecached, sodass du den Performance-Unterschied nicht mehr merkst (da dann
beides langsam ist) ;)
Stichpunkte zur Performance-Optimierung: Rushmore, Rushmore und Rushmore.
Vollkommen egal, ob du direkte USEs machst, ob du SET FILTER verwendest,
oder SQL-Selects und Views mit WHERE verwendest: Wenn bei der
Index-Erstellung und Abfrage/Filter-Optimierung geschlampt wurde, werden
halt zu viele Daten durch den Strohhalm namens "Netzwerkkabel" gelutscht.
Und je nach Schneckenfaktor des Netzwerks hast du eben mehr oder weniger
performante Anwendungen. Drum sollte man auch nie nur lokal testen, sondern
immer noch einen Rechner mit einer auf 10Mbit gedrosselten Netzwerkkarte
haben.
Hast zB überall einen Index auf DELETED() und vom Typ BINARY gemacht?
Allein das kann schon Wunder bewirken... Ansonsten wurden hier in den
Foren, auf den Konferenzen und selbst in der VFP Hilfe (oh Wunder) mit
schöner Regelmässigkeit das Thema Abfrage-Optimierung behandelt.
--
Jürgen Wondzinski
Microsoft Visual FoxPro Technologieberater
Microsoft Most Valuable Professional seit 1996
"*??)
?..??..*??) ?..*?)
(?..?. (?..` *
..`.Visual FoxPro: It's magic !
(?..``..*
werner meyer
dass die Netzwerk Verbindung langsamer ist wie die lokale ist klar.
Nur sollte die Netzwerk Verbindung für den Benutzer erträglich sein
und das ist Sie eben leider nicht.
Wenn der Benutzer Positionen erfasst und nach jeder Position eine Pause
einlegen muss ist das nicht ok.
Wie gesagt es genügt wenn der 1. Benutzer das Programm nur startet -
dann geht die Geschwindigkeit beim 2. Benutzer in die Knie.
Zur Sicherheit noch einmal:
Wenn nur der 2. Benutzer über das Netzwerk ins Programm geht ist die
Erfassung sehr schnell.
Wenn mich nicht alles täuscht hast Du das opportunistischem Sperren
empfohlen.
Ich habe das versucht - die Geschwindigkeit hat sich jedoch nicht
verbessert.
Michael Bickel
interessant, dass ich gerade die Anfrage eines Kunden erhalten habe,
der ein ähnliches Problem beschreibt - wobei hier das Öffnen der
Datenbanken
auf dem 2. PC sehr langsam ist.
Auf unseren Rechnern und auch allgemein als solches taucht es aber
nicht auf.
(unter Vista habe ich bei aktivierter Benutzerkontensteuerung
allerdings das Problem, dass sich das Netzwerk nach gegebener inaktiver
Zeit deaktiviert - ganz toll bei geöffneten Datenbanken).
Der Kunde hat GData Antivirenkit 2006 im Einsatz. Über die
Rechnerausstattung kann ich nichts sagen.
Eventuell liegt ja im verwendeten Virenscanner eine Ursache?
Viele Grüße
Michael
werner meyer wrote:
--
Jürgen Wondzinski
ABzuschalten! Ein eingeschaltetes OppLock führt zwar zur Beschleunigung
immer dann wenn nur 1 User die Datei in Verwendung hat, verursacht aber auch
gleichzeitig Probleme bei normalem Multiuser-Betrieb. Dies ist KEIN
"NurFoxPro"-Problem, es betrifft durchgängig alle dateibasierten
Datenbank-Produkte. Daher findest du beim netsprechenden Googlen überall das
passende Wehklagen...
Wenn die Netzwerkgeschwindigkeit für "normale User unerträglich" ist, dann
ist schlicht ein Netzwerk-Problem da. Man konnte selbst zu Zeiten von Arcnet
oder den 10Mbit Ring-Leitungen problemlos im Netzwerk arbeiten, auch mit 100
Usern gleichzeitig.
Ob nun ein Steckdosen-Netzwerk tatsächlich die selbe Übertragungsrate und
Antwortverhalten wie ein normales Netzwerk hat, weiss ich nicht. Aber, wie
schon gesagt: Selbst mit simplen Tests kannst du ausprobieren, ob zumindest
die Datenrate mithalten kann.
>> Ich habe das versucht - die Geschwindigkeit hat sich jedoch nicht
>> verbessert. <<
Les noch mal, was ich dir geschrieben habe:
.... Durch das Setzen der Registry-Keys wird auch im Einzelbenutzer-Modus
nicht mehr gecached, sodass du den Performance-Unterschied nicht mehr merkst
(da dann beides langsam ist) ;) ....
Da steht nix davon, dass es dadurch schneller würde?
--
Jürgen Wondzinski
Microsoft Visual FoxPro Technologieberater
Microsoft Most Valuable Professional seit 1996
"*´¨)
¸.•´¸.•*´¨) ¸.•*¨)
(¸.•´. (¸.•` *
.•`.Visual FoxPro: It's magic !
(¸.•``••*
Olaf Doschke
> empfohlen.
> Ich habe das versucht - die Geschwindigkeit hat sich jedoch nicht
> verbessert.
Nein, es wird immer wieder nur empfohlen diese
Form von Vorgaukelung exklusiven Zugriffs nicht
zu nutzen, weil nur ein einzeln auf einer Tabelle
arbeitender User davon profitiert, sobald ein
zweiter dieselbe Tabelle nutzt gibt es dabei sogar
den Overhead, daß erstmal die Änderungen des
1. Benutzers wirklich zurück zum Server müssen,
bevor der 2. auch nur überhaupt lesen kann, sonst
würde der ja etwas veraltetes vom Server kriegen.
Es ist besser das von vornherein gar nicht zu
aktivieren.
Tschüß, Olaf.
Hans-Peter Grözinger
> Wenn der Benutzer Positionen erfasst und nach jeder Position eine
> Pause einlegen muss ist das nicht ok.
Teste mal den Netzwerk-Durchsatz mittels NETIO:
http://www.nwlab.net/art/netio/netio.html
PS: Bei einem 100 MBit-Netzwerk sollte man zwischen 8000 und 12000
KByte/s und bei 1000 MBit zwischen 50000 und 100000 KByte/s
erreichen können.
--
Hans-Peter Grözinger
TOFU ist gedankenlose Resourcenverschwendung.
http://einklich.net/usenet/zitier.htm
http://support.microsoft.com/default.aspx?scid=fh;DE;NGNetikette
Michael Bickel
> Nein, ich bzw generell wird empfohlen, das "Opportunistic Locking"
> ABzuschalten! Ein eingeschaltetes OppLock führt zwar zur
> Beschleunigung immer dann wenn nur 1 User die Datei in Verwendung
> hat, verursacht aber auch gleichzeitig Probleme bei normalem
> Multiuser-Betrieb. Dies ist KEIN "NurFoxPro"-Problem, es betrifft
> durchgängig alle dateibasierten Datenbank-Produkte. Daher findest du
> beim netsprechenden Googlen überall das passende Wehklagen...
>
Notes for Windows Vista: The opportunistic locking registry keys are
valid only for traditional SMB (SMB1). You cannot turn off
opportunistic locking for SMB2. SMB2 was introduced in Windows Vista to
enable faster communication between computer that are running Windows
Vista and Windows Server Code Name "Longhorn."
• If you disable opportunistic locking, the offline files feature in
Windows Vista fails.
Also unter Vista kann man es wohl nicht ausschalten?
Die einschlägigen Registry keys existieren auf jeden Fall nicht.
Viele Grüße
Michael
--
Olaf Doschke
> valid only for traditional SMB (SMB1). You cannot turn off
> . If you disable opportunistic locking, the offline files feature in
> Windows Vista fails.
Was sich ja schonmal irgendwie widerspricht. Man kanns nicht
ausschalten, aber wenn mans ausschaltet, geht Offline Files
nicht. Aha, also kann man's doch ausschalten, oder?
> Die einschlägigen Registry keys existieren auf jeden Fall nicht.
Das tun sie bei XP auch meist nicht.
Wenn ein Key nicht existiert gilt der Defaultwert.
Also legt man den Key an und stellt ihn auf den
Wert, der Oplocks ausschaltet.
Und dann braucht man halt SMB1.
Tschüß, Olaf.
Michael Bickel
ich sage nicht, dass das richtig ist, denn
... das ist nicht auf meinem Mist gewachsen, sondern ich
habe aus diesem Artikel zitiert:
http://kbalertz.com/296264/Configuring-Opportunistic-Locking-Windows.asp
x
The location of the client registry entry for opportunistic locking has
changed from the location in Microsoft Windows NT. In later versions of
Windows, you can disable opportunistic locking by setting the following
registry entry to 1:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MRXSmb\Parameters\
OplocksDisabled REG_DWORD 0 or 1
Default: 0 (not disabled)
Note The OplocksDisabled entry configures Windows clients to request or
not to request opportunistic locks on a remote file.
Bei mir existiert der ganze Zweig Parameters unter Vista nicht.
Unabhängig davon ist es aber nicht besonders komfortabel Kunden zu
empfehlen in der Registry herumzufummeln. Insbesondere, wenn man, wie
unter Vista nicht wirklich sicher ist, was zu ändern ist und wenn
(doch) wie.
Gibt es dafür ev. ein Utility?
Viele Grüße
Michael
Olaf Doschke wrote:
--
Olaf Doschke
> Gibt es dafür ev. ein Utility?
enthält. Mit Adminrechten natürlich.
Die REG-Datei erstellen, indem man in regedit die
Keys exportiert.
Tschüß, Olaf.
Olaf Doschke
> habe aus diesem Artikel zitiert:
>
> http://kbalertz.com/296264/Configuring-Opportunistic-Locking-Windows.aspx
Sorry, ich meinte auch nicht Dich, ich kenne den Abschnitt.
http://support.microsoft.com/kb/296264/en-us
Ich hab mich schonmal früher darüber amüsiert.
Lies auch mal hier nach in einer Doku zu Samba:
http://gertranssmb3.berlios.de/output/locking.html
Mehrbenutzer-Datenbanken
Mehrbenutzer-Datenbanken stellen klarerweise durch ihre grundlegende Natur
ein Risiko dar auf sie wird üblicherweise massiv von vielen Anwendern in
zufälligen Intervallen zugegriffen. Das Platzieren einer
Mehrbenutzer-Datenbank auf einer Freigabe mit aktivierten Oplocks wird
wahrscheinlich zu einem Flaschenhals auf dem Samba-Server führen, weil die
Sperren verwaltet werden müssen. Egal, ob eine Datenbank eine
Eigenentwicklung ist oder ein kommerzielles Produkt, stellen Sie sicher,
dass die entsprechende Freigabe deaktivierte Oplocks hat.
Tschüß, Olaf.
Michael Bickel
... wenn ich es richtig verstehe, dann sollte man es auf dem PC oder
Server ausschalten, auf dem die Daten gelagert sind? oder/und auch auf
dem PC, wo das Programm gestartet wird (bzw. halt allen PCs)
Kann man denn definitiv sagen, ob dies auch unter Vista funktioniert?
Sorry, falls ich eine dumme Frage stelle, aber mitunter finde ich diese
MS Informationen so umständlich und kompliziert formuliert, dass mir
danach Dinge nicht wirklich klarer sind oder zumindest Zweifel bleiben.
Es ist wohl ein großes Problem für ITs Dinge (nicht nur bei MS, aber
die sind zumindest ein gutes Beispiel dafür) verständlich zu
formulieren.
Viele Grüße
Michael
Olaf Doschke wrote:
--
Christof Wollenhaupt
VFP ist sehr empfindlich bei der Latenzzeit des Netzes, also der Zeit, die
es dauer, ein Paket zu übertragen und die Bestätigung dafür zu erhalten, da
VFP viele kleine Pakete nacheinander sendet oder liest. Latenzzeit ist bei
DSL zum Beispiel sehr hoch, bei Ethernet niedrig.
Es gibt außerdem einige Flaschenhälse, die den gleichzeitigen Zugriff
deutlich verlangsamen, da immer nur einer im Netz diese Aktion pro Tabelle
ausführen kann:
- Anlegen eines Satzes
- Erhöhung des Wertes eines AUTOINC Feldes
- Schreiben eines Indexeintrages durch Änderung eines indizierten Feldes
- Schreiben eines Memofeldes
- Prüfen der Datei beim Öffnen einer Tabelle (SET TABLE VALIDATE)
Außerdem wird VFP bei der Verwendung von großen indizierten Tabellen
langsamer, da jede Änderung eines indizierten Feldes mehrere Blöcke in der
Indexdatei betrifft.
--
Christof
Olaf Doschke
You can also deny the granting of opportunistic locks by setting the
following registry entry to 0:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
EnableOplocks REG_DWORD 0 or 1
Default: 1 (enabled)
Note The EnableOplocks entry configures Windows-based servers to allow or to
deny opportunistic locks on local files. These servers include workstations
that share files.
Den Eintrag machst Du am Server.
Danach sollte es egal sein, ob Clients Oplocks
anfordern, der Server vergibt sie nicht. Die Clients
verschwenden jedoch Zeit mit der Anfrage eines
Oplocks.
Tschüß, Olaf.
Michael Bickel
Viele Grüße
Michael
Olaf Doschke wrote:
> Der Asbchnitt ist der entscheidende:
>
> You can also deny the granting of opportunistic locks by setting the
> following registry entry to 0:
> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Para
> meters EnableOplocks REG_DWORD 0 or 1 Default: 1 (enabled)
> Note The EnableOplocks entry configures Windows-based servers to
> allow or to deny opportunistic locks on local files. These servers
> include workstations that share files.
>
> Den Eintrag machst Du am Server.
>
> Danach sollte es egal sein, ob Clients Oplocks
> anfordern, der Server vergibt sie nicht. Die Clients
> verschwenden jedoch Zeit mit der Anfrage eines
> Oplocks.
>
> Tschüß, Olaf.
--
Uwe Niemeyer
die beschriebenen Probleme kommen mir sehr bekannt vor:
So lang unsere Foxpro 2.6-Datenbank (> 400000 Sätze) unter Samba 2.2.8a lief
war der Datenzugriff kein Problem und jede Station startete etwa
gleich schnell, wobei die Oplocks auf dem Server deaktiviert waren.
Nach der Umstellung auf Samba 3 startete die 1te Station schnell,
ab der 2ten wurde alles langsamer. Völlig gefrustet haben wir auf
auf eine Windows 2003 Homeserver umgestellt (mit 2003-Kern).
Ergebnis: Das gleiche Verhalten.
Nach langem Suchen und Oplock-Test-Aktionen, die alle nichts mehr
brachten brachte folgendes Vorgehen die Lösung:
für Win-Server:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters]
"Sharingviolationretries"=dword:00000000
"Sharingviolationdelay"=dword:00000000
Dieser Parameter wurde mit dem Windowsserver eingeführt und Samba hat
wohl zwecks besserer "Emulation" diesen Wert auch übernommen ab 3.0.6.
Dort ist er einstellbar über
[global]
defer sharing violations= yes/no default=no
"Beschreibung:
Windows erlaubt die Spezifizierung, wie eine Datei mit anderen Prozessen
geteilt werden soll, wenn diese geöffnet ist. Sharing violations treten auf,
wenn eine Datei von einem unterschiedlichen Prozeß mit Optionen geöffnet
wurde, die die spezifizierten share-Einstellungen eines anderen Prozesses
verletzen. Dieser Parameter veranlaßt smbd, sich wie ein Windows Server zu
verhalten, und hält die sharing violation Fehlermeldung für eine Sekunde
zurück, um dem Client in der Zwischenzeit die Möglichkeit zu geben, die
Datei, die die Verletzung ausgelöst hat, zu schließen."
vgl. hierzu für .mdb:
http://www.unixboard.de/vb3/showthread.php?t=30632
Unsere VFP 2.6-Datenbank bearbeitet die Dateizugriffe/-konflikte selbst.
Wenn jetzt noch das "timeout" des Servers bei Zugriffsverletzungen
auftritt (jeweils 1 Sek.) muss ab der 2ten Station zusätzlich auf die
Bestätigung des Servers gewartet werden.
Ob das bei VisualFoxpro auch so ist kann ich nicht sagen.
Bei Foxpro 2.6 haben die Servereinträge unser Problem jedenfalls gelöst.
Viele Grüße
Uwe Niemeyer