Netzwerkperformance

[Rudolf]

Hallo Tom, Jimmy,
wie gesagt, hab an allem herumgedreht was es so an Empfehlungen gibt, konnte keine Änderung in der Geschwindigkeit feststellen.
Das Problem ist nachvollziehbar, aber ich kann nicht meine Rechner samt Netzwerk mit der Applikation zu Alaska schicken. Habe auch nicht die Möglichkeit bei jedem Kunden alle möglichen Einstellungen auszuprobieren bis alles läuft. Ich bezweifle dass es überhaupt an irgendwelchen Einstellungen liegt, wenn ja, dann hätte sicher schon jemand das Problem gelöst. Meiner Meinung nach liegt hier bei Alaska Handlungsbedarf, aber leider keine zielführenden Antworten auf alle meine Anfragen.
Grüsse
Rudolf

[AUGE_OHR]

hi

Meiner Meinung nach liegt hier bei Alaska Handlungsbedarf, aber leider keine zielführenden Antworten auf alle meine Anfragen.

YUP da gebe ich dir Recht, aber deiner Schlussfolgerung sehe ich nicht.
Wenn es so wäre wie du sagt dann würde ja keine von "unseren" Xbase++ Applicationen laufen ?!

Also ich bleibe dabei Hotfix No#8/12

[Rudolf]

wieso keine ? die meisten laufen ja, ist leider ein Glücksspiel
Grüsse
Rudolf

[Jan]

Jimmy,

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.

Mag sein. Aber das ist doch genau das Problem: Alle anderen Programme laufen auf dem Rechner problemlos und mit normaler Geschwindigkeit. Auch das Xbase++-Programm. Nur die Browses brauchen immer eine Denkpause von ein paar Sekunden, bis die angezeigt werden. Der Grund ansich mag also vielleicht in der Windowsinstallation oder der Hardwarekonfiguration liegen. Aber alle anderen Programme kommend damit einwandfrei klar. Nur die Browses nicht.

Und das ist genau das gleiche mit den Netzwerken. Vielleicht liegt es an einer bestimmten Konfiguration. Oder an den Netzwerkkarten. Oder sonstwas. Aber alle anderen Programme kommen damit klar. Nur beim Xbase++-Programm bricht die Performance ein. Wo liegt also der "Fehler"? Wer ist also der "Schuldige"? Ursächlich vielleicht in der Tat das Betriebssystem, die Konfiguration, oder die Hardware. Aber alle anderen Softwarepakete können damit umgehen oder das abfangen. Also sind hier in den Augen der Kunden wir als Entwickler des Programmes die Schuldigen.

Jan

[Rudolf]

Hallo Jan,
genau das ist mein Problem, ich kann beim Kunden nicht argumentieren, da ich nicht weiss woher. Also liegt für den Kunden das Problem bei mir.
Grüsse
Rudolf

[brandelh]

Hi,

ich denke, dass es in solchen Fällen meinst nicht ein Problem ist, sondern dass mehrere zusammenkommen.

1. Grundsätzlich ist Xbase++ recht lahm (auch wenn man das nicht gerne hört).
2. Das spielt keine Rolle, solange man einen Satz liest und dann die 20 oder 30 SLE (Win-Control) füllt.
3. Der Browser ist aber noch viel lahmer, denn bei dem wird jedes Kästchen aus mehreren Static erzeugt. -> Besser XbpQuickBrowser() nutzen, wenn es nur um Anzeigen geht.
Dieser nutzt mit den DAC... Funktionen auch ein flexibleres Nachladen.
4. Wenn die Anzeige gefiltert werden muss, dauert das auch Zeit, wobei die Reihenfolge der Daten dann sehr wichtig ist.
5. Wenn mehrere DBF mit SET RELATION verbunden sind, kann es zu "Kettenreaktionen" kommen ...
6. Virenscanner wie F-PROT oder G-DATA zwingen meinen Athlon 64 auf träges PIII Niveau zurück.
Wehe wenn die auch auf dem Server laufen.
7. 3D-Bildschirmschoner oder DOS Programme auf dem Server und man kann gleich einpacken !
8. Plattenfragmentation ... obwohl die DBF ja eher klein sind.

all dies läst sich kaschieren, solange die Daten noch in den Festplatten / Rechner Cache passen, aber wenn dann ein zweiter PC noch dazu kommt und die eh überlasteten Platten nun tatsächlich suchen müssen, wird es einfach zuviel.

Die Servereinstellungen sind sicher wichtig, insbesondere wegen Problemen bei Abstürzen (z.B. Stromschwankungen) - je weniger Cache um so sicherer ...
Aber wenn ich lese, dass 2 PC mit 2 Programmen deswegen in die Knie gehen sollen, kann ich das nicht glauben.

Wie schon öffters gesagt, wir greifen mit meinen DBFNTX Programmen von 3 Terminalservern (normalerweise zwischen 5 und 10 Sessions gleichzeitig) auf ein freigegebenes Laufwerk eines Datenbankservers zu, ohne dass dort Änderungen gemacht wurden. In diesen Clipper-like Anwendungen wird kein Browser benutzt. In meinen GUI Anwendungen bin ich von direkten Netzzugriffen wegegangen, da diese über 128 KBit WAN-Leitungen (alte Umgebung) nicht mehr tragbar waren. In diesen Programmen werden zuerst alle Daten eines Falles in Arrays geladen, bearbeitet und danach wieder von dort gespeichert.
Natürlich geht das nur dann, wenn man wie hier eine Akte wie ein Worddokument öffnet, bearbeitet und wenn man will speichert oder einfach verwirft. Alles was wie ein Browser regelmäßige und massive Dateizugriffe provoziert, sollte man vom Design überdenken um der Maschine Arbeit abzunehmen ... eventuell auch am Anfang nur 20 Sätze laden um dann nachzuladen ... so einen Artikel gibt es auf Alaska ...

[Rudolf]

Hallo Hubert,
unter Terminalserver läuft alles blitzschnell, sogar schneller als bei mir lokal. Ist die bevorzugte Installation für mich und ich empfehle es jeden Kunden.
Grüsse
Rudolf

[Tom]

"Andere Programme laufen ganz normal" ist ein Scheinargument, und wenn damit Office-Programme gemeint sind, vergleicht man Äpfel mit Glühbirnen. Der übliche Office-Krempel arbeitet mit einzelnen Dokumenten, die komplett in den lokalen Arbeitsspeicher geladen werden, was selbst bei äußerst unzureichend konfigurierter Netzwerktopologie und laden vom Server noch so schnell geht, dass es kaum spürbare Latenzen gibt. Demgegenüber wühlen Datenbankanwendungen in verteilten Datenbanken herum, springen zu einzelnen Datensätzen, halten tonnenweise Tabellen offen und dazu noch Indexe, Memodateien und vieles mehr. Jede Dateioperation in Standardbrowses ist eben auch eine OS-Dateioperation (eigentlich aber hunderte davon). Das ist bei Office und sogar bei Access-Anwendungen grundsätzlich anders und deshalb weder vergleichbar, noch ein Hinweis darauf, dass alles in Ordnung ist.

Ich würde empfehlen, mal ein Tool wie "Filemon" (das heißt jetzt m.E. "Procmon" und ist kostenlos beim M$ erhältlich) laufen zu lassen, entweder bezogen nur auf die Anwendung oder - besser - auf dem Server gefiltert auf das Datenbankverzeichnis. Da kann man im Log sehr schön sehen, welche Dateioperationen - es sind insgesamt nur eine Handvoll API-Requests - durchgeführt werden und wie lange sie dauern. Und, vor allem, von wem sie ausgeführt werden. Das vergleicht man dann mit den Operationen der Anwendung, die ja vermutlich lokal läuft und auf den Server zugreift. Und mit den Ergebnissen der Terminal-Server-Installation. Es dürfte recht leicht sein, hier herauszufinden, wo der Hase begraben ist. Notfalls erstellt man eine simple Beispielanwendung mit einem Browse oder so und testet für diese, was passiert. Ich bin ziemlich sicher, dass es technische Ursachen abseits der Anwendung selbst geben muss.

[Rudolf]

Hallo Tom,
das mit den Officeprogrammen kann ich den Kunden schon klarmachen. Leider ist XBase++ meistens das einzige Programm welches derart übers Netzwerk arbeitet, daher beim Kunden nicht vergleichbar mit anderen Programmen.
Das mit dem Tool von MS ist ein guter Tip, werds mir mal anschauen.
Grüsse
Rudolf

[Jan]

Hallo Tom,

falls Du damit auf meine Bemerkungen ansprechen möchtest: Mir ist absolut klar, daß man MS Word nicht mit einer Datenbankanwendung vergleichen kann. Das hatte ich ja gestern in meinem Beitrag von 17:51 Uhr angemerkt. Wobei manche "normalen" User den Unterschied nicht sehen (wollen).

Aber auf dem betreffenden Rechner bei mir liefen parallel sowohl Sage KHK als auch unsere Access Warenwirtschaft. Also beides sicher Programme, die massiv mit Datenverkehr arbeiten.

Außerdem: Ich selber hab ja kein Netzwerkproblem. Die Geschichte mit den Browses ist
1) nur ein Beispiel gewesen für das ab und an merkwürdige Verhalten von Xbase++-Programmen in nicht nachvollziehbaren Situationen.
2) auch in einem komplett lokal aufgetrenen Szenario aufgetreten. Das hatte ich versucht, weil ich das erst auch auf ein Netzwerkproblem geschoben hatte.

Aber vielen Dank für die Hinweise zu den Tools. Wobei die bei uns sicher nur lokal zu gebrauchen sind, da wir ausschließlich Linux-Server haben. Ich setze voraus, daß die erwähnten MS-Tools nur auf Windows-Servern laufen. Sollte es anders sein würde ich mich freuen.

Jan

[Tom]

@Jan: Procmon kann auch lokal laufen. Wenn es eine lokale Anwendung überwacht, die auf dem Server Dateien öffnet, ist unerheblich, welches OS dort läuft. Hier gibt's das Tool:

http://technet.microsoft.com/en-us/sysi ... 96645.aspx

[Tom]

Ein kleiner Hinweis am Rande, vielleicht betrifft das ja jemanden: Wir arbeiten tatsächlich teilweise noch mit XPF-Dateien, sind aber dabei, das meiste an zu speichernden Memvars (Voreinstellungen usw.) nach XML auszulagern. Wie auch immer. Obwohl XPF-Dateien meistens nicht sehr groß sind, hat sich gezeigt, dass der Ladevorgang von XPFs, die z.B. 500 Memvars enthalten, von einem Server unglaublich lange dauern kann, weil der Lesevorgang technisch (Steffen hat mir das mal erklärt) anders läuft - vereinfacht gesagt wird die Datei für jede einzelne Var geöffnet, dann wird die Speichervariable gelesen und die Datei wird wieder geschlossen (oder so ähnlich). Lokal (also auch unter Terminal Server) geht das blitzschnell, aber direkt vom Server dauert es. Manchmal fünf, zehn Sekunden oder mehr. Deshalb kopieren wir größere XPF-Dateien ins lokale Temp-Verzeichnis und lesen von dort, beim Schreiben wird umgekehrt verfahren. Das hat diesen Vorgang extrem beschleunigt. Sollte also irgendwo in einer Anwendung ein wiederholt angesprochenes RESTORE FROM oder SAVE TO stecken, könnte auch hier der Hase begraben sein.