Xbase-Benchmark - Workshop?

[Tom]

Ich hatte gestern (wieder mal - ich hatte sie früher schon) die Idee, ein Tool zu entwickeln, mit dem Anwender von Xbase++-Lösungen die Performance ihrer Arbeitsplatzrechner und (!) des Netzwerks überprüfen können. Vermutlich bin ich nicht der einzige, der mit schwachbrüstigen Netzwerken und unglücklich konfigurierten Virenscannern konfrontiert wird. Oder mit Arbeitsplätzen, die mit 256 MB Hauptspeicher ausgerüstet sind, auf denen aber Vista "läuft", und alles mögliche an Autostart-Anwendungen.

Die Idee: Eine Xbase++-Anwendung prüft zuerst lokal die eigene Ablaufgeschwindigkeit bei Rechenoperationen, bei GUI-Komponenten (Dialogaufbau und -zerstörung) und bei Datenbankoperationen (Create Table, Datei füllen, Indexaufbau, Suchoperationen, Packing). In der zweiten Stufe loggt sich diese Anwendung bei einer Komponente, die auf dem Server läuft (Xb2.Net?) ein und wartet auf einen "Startschuss", so dass sich mehrere Benchmarks synchronisieren können - im Idealfall also wird auf allen Arbeitsplätzen zeitgleich dieses Tool gestartet, und erst wenn alle angemeldet sind, gibt die Serveranwendung ihr Okay. Dann wiederholen die lokalen Komponenten die Dateioperationen auf dem Server. Zuerst nacheinander und dann gleichzeitig. Als Ergebnis sollte man "Kennzahlen" über die Leistungsfähigkeit der Arbeitsplätze und des Netzwerks bekommen.

Das ganze dürfte nicht sehr aufwendig sein; das Hauptproblem besteht m.E. einerseits darin, die Serverkomponente zu entwickeln (aber auch das ist eigentlich kein Ding). Andererseits muss für die echte Vergleichbarkeit der Ergebnisse in irgendeiner Hinsicht ein Maßstab gefunden werden. Einfach irgendeine Zahl anzuzeigen (das Erzeugen einer Tabelle mit 100.000 Datensätzen dauert lokal 3,27 und auf dem Server 17,55 Sekunden - aha) dürfte letztlich nicht sehr hilfreich bzw. aussagekräftig sein. Deshalb müsste man bereits eine Skala bzw. irgendeine Datenbasis mitliefern, um Aussagen der Art "guter Durchsatz" oder "mangelhafte Performance - bitte prüfen Sie dies und das" treffen zu können. Hierfür, aber auch für die Entwicklung eines solchen Tools, wäre es sinnvoll, möglichst viele Testergebnisse bereits im Vorfeld als Vergleichsbasis heranziehen zu können. Hierfür, aber auch für die eigentliche Entwicklung möchte ich ein Workshop hier im Forum vorschlagen.

Interesse?

[Koverhage]

Hallo Tom,

gute Idee. Meinerseits besteht Interesse.

[Wolfgang Ciriack]

Klingt auch für mich interessant.

[AUGE_OHR]

Andererseits muss für die echte Vergleichbarkeit der Ergebnisse in irgendeiner Hinsicht ein Maßstab gefunden werden. Einfach irgendeine Zahl anzuzeigen (das Erzeugen einer Tabelle mit 100.000 Datensätzen dauert lokal 3,27 und auf dem Server 17,55 Sekunden - aha)

Als Maßstab könnte man zunächst mal GETENV("PROCESSOR_LEVEL") nehmen wie ich
es in meiner DBESYS.PRG machen. Nun bräuchte man noch mehr Hardware Informationen um
die Skala "feiner" zu tunen.

Beim "anlegen","seek" etc. von DBF sollte man die "Praxis" nicht vergessen. Dort erweist sich
ein Browse als "Problem" ... also brauchen wir einen "Skipper" der schön Last erzeugen kann.

Bei DBF, glaube ich, geht alles mit 4Kb Blöcken ab so das man die Cluster Grösse der FAT/NTFS
berücksichtigen müsste.

FWrite() liefert, denke ich, keine Werte die man mit DBF vergleichen kann.
FRead() wäre beim einlesen von Daten interessanter ... oder mit DBFxxx ?

auch wäre NTX / CDX als Tabelle mal interessant

GFK ... keine Ahnung ... aber DX9/128Mb ist ja wohl jetzt "Pflicht".

Netzwerk ... meistens durch das Server OS() mit Cache ! ... oder Op´s Lock Probleme ?

Netzwerk Drucker ?

so ich fange mal die erste Zeile an

Code: Alles auswählen

Procedure MAIN
    DoBenchmark()
   // hier auffüllen 
Return

[Rolf Ramacher]

Hi Tom,

das klingt sehr interessant. Das könnte mal man gebrauchen.

[Koverhage]

Brauchen könnten es wahrscheinlich viele, aber hier ist ja auch die Mitarbeit gefragt.

Erstmal sollte man die Spezifikation festlegen.
z.B. wie Jimmy schon geschrieben hat.

OS()
Prozessor()
Speicher()
Grafikkarte()
Netzwerkkarte()
wichtig hierbei ist welche Geschwindigkeit eingestellt ist, denn die sollte fest vorgegeben sein und nicht auf AUTO stehen
Plattenspeicher()
natürlich alles jeweils für Server und Arbeitsstation

dann natürlich wie Tom geschrieben hat
Datenbankoperationen
(lokal und Server)

Danach gibt es 2 Möglichkeiten: Entweder schreibt man die Ergebnisse in eine DBF und/oder über ActiveX in eine Excel Tabelle,
so hätte man einen kleinen Benchmark für ActiveX.

Hoffe ich bin nicht zu weit vorgeprescht.

Da es ein Gemeinschaftsprojekt sein soll, würde ich vorschlagen man teilt das in Module auf und für jedes Modul gibt es einen
der es erstellt.
Vielleicht hat ja schon jemand einen Teil von den Routinen (z.B. Jimmy das Betriebssystem Gedöns)
und stellt es dann zur Verfügung.

[AUGE_OHR]

hi,

OS()
Prozessor()
Speicher()
Grafikkarte()
Netzwerkkarte()
wichtig hierbei ist welche Geschwindigkeit eingestellt ist, denn die sollte fest vorgegeben sein und nicht auf AUTO stehen
Plattenspeicher()
natürlich alles jeweils für Server und Arbeitsstation

Vielleicht hat ja schon jemand einen Teil von den Routinen (z.B. Jimmy das Betriebssystem Gedöns)
und stellt es dann zur Verfügung.

ist fertig... mit WMI (Windows Management Instrumentation)

in der SL1 ist ComEvalCollection() dazu gekommen und wir nun vom Usertreffen wissen kann man
damit endlich auch auf WMI zugreifen. Das habe ich nun versucht in einer Demo zu verwirklichen
und das funktioniert auch recht gut.

Leider "müsste" man den Code und alle Property ja "schreiben" und so dachte ich über einen
"Generator" nach der auf Mausclick die Property anzeigt und deren Inhalt. Das scheint auch zu
funktionieren ... zumindest "im Prinzip" den zu jedem der o.g. Punkte kann ich "per Mausclick"
einen lauffähigen Xbase++ Code mit FWrite() erzeugen. Das ganze habe ich in einem Codebock
den ich "per Maus" zusammen stellen kann woraus der Source generiert wird.
http://www.xbaseforum.de/viewtopic.php? ... &hilit=wmi

schade eigentlich das wir jetzt erst darauf gebracht wurden, den ComEvalCollection() ist wohl
schon einige Zeit in der SL1 gewesen und keiner wusste mit der Demo was anzufangen

[Rudolf]

Hallo Tom,
wirklich eine super Idee, habe einige sehr wichtige Kunden wegen der teilweise extrem schlechten Performance im Netzwerk verloren, war nicht rauszufinden wo die Ursache liegt. Habe auch die Kunden diesbezüglich verstanden, daher installiere ich nur mehr auf Terminalserver, da gibt es kein Problem bis jetzt. Ich hatte Installationen in sehr professionell gewarteten Netwerken, die extrem langsam waren, und Installationen auf uralten Rechnern von Bastlern, die im Netwerk total schnell waren. Habe bis heute den Unterschied nie rausgefunden. Aber ich kenne die Szenarien um dieses Problem zu testen, ist großteils nachvollziehbar.
Grüsse
Rudolf

[AUGE_OHR]

wegen der teilweise extrem schlechten Performance im Netzwerk verloren, war nicht rauszufinden wo die Ursache liegt.

geht nicht, gibst nicht ... alles nur eine Frage der Zeit (und des Geldes)

obwohl wir ja "nur" die Software erstellen, werden wir von unseren Kunden oft auch für die
Hardware verantwortlich gemacht wenn was nicht funktioniert. Ist das bei einem "Single" PC
noch in Griff zu bekommen so wird das beim Netzwerk schon schwerer weil es ja mehrer PC´s
+ Server sind.

schon unter Novell hatte ich da mit meinen Kunden zu "kämpfen", den die wollten "alles" auf dem
Server machen wogegen ich protestiert habe. "Meine" Anwendungen bekommen ihren "eigenen"
Server und der kommt von mir ( Installation ) und sonst gibt es keine "Wartung". Ausnahme nur
wenn ich den Source statt Application abgebe, denn dann können die mit dem Source machen
was die wollen.

auch muss es ein "dedizierter" Server sein d.h. nicht gleichzeitig Workstation wo jemand daran
arbeitet wie in einem Peer-2-Peer Netzwerk oft üblich.
wie schon gesagt einen reiner "Daten" Server (naja auch Print/Fax Server) für *.DBF ist meine
"Bedingung" für meine Applicationen und auch der "Zugriff" auf den Server ist nur über "meine"
Applicationen erlaubt. Wenn jemand für Excel & Co. was braucht, dann werden die Daten
exportiert in eine temporäre DBF auf dem "öffentlichen" Server durch "meine" Applicationen
die auch dafür die Daten "entschlüsseln" muss.

Die Kosten "meines" Server sind im Verhältnis zu den möglichen "Unverträglichkeiten" meiner
Applicationen zu M$ Produkten bei den heutigen Hardware Preisen zu vernachlässigen. Dafür
kann ich aber "meinen" Server entsprechend optimieren z.b. Registry oder mehrere Laufwerke.

Ich rede hier nun nicht von Servern für 250 Personen oder mehr, den da wird wohl kaum noch
jemand dafür *.DBF nehmen, sondern eher von 10-50 Personen und dafür reicht ein P4 mit W2K
wie er oft bei den Kunden noch "rumsteht". Der wird dann "platt" gemacht, RAM und HD aufrüsten
sowie eine externe 1000mMbit Netzwerkkarte und fertig. Backup und USV ist eh Kunden Sache
und somit habe ich dann meine Ruhe was Hardware Probleme angeht.

Das heisst aber nicht das ich in der Lage bin einen "optimalen" *.DBF Server "hin-zu-stellen",
den die "Bedingungen" sind ja bei jedem Kunden anders. Jedesmal wenn ich also beim Kunden
bin sehe ich mir die Logfiles an und "drehe" hier und da ein wenig rum... so ca. 6 Monate brauche
ich, bei "konstanter" Hardware, bis ich zufrieden bin ... aber wenn neue Hardware kommt geht
das Spiel wieder von vorne los...

[Rudolf]

Hallo Jimmy,
mich würde aber trotzdem interessieren, wieso bei einem Kunden mit einem alten, nicht besonders leistungsfähigen Bastler PC als Server das selbe System im Netz sehr schnell läuft, bein anderen mit professionellem Server und den selben Einstellungen in Registry sehr langsam im XBase++ ist. Das zu ergründen erhoffe ich mir hier aus dem Projekt, dann kann ich das System auf jedem Server installieren. Nicht jeder akzeptiert einen eigenen Server für die XBase++ Anwendung.
Grüsse
RUdolf

[brandelh]

Hi Jimmy,

deine "Vorgaben" würde keiner schlucken, den ich kenne

Ich hatte noch nie Probleme im lokalen Netz, vermeide aber alles was sofort ein Schreiben
in eine DBF erfordert, sobald ein Feldwechsel vorliegt.
Alle meine Programme cachen den aktuellen Satz.
Die neueren sogar den kompletten Aktenfall, wobei dies natürlich nicht immer geht.
Statt XbpBrowse() nehme ich normalerweise XbpQuickBrowse() mit den DAC... Funktionen/Objekten,
das spart enorm viel Dateizugriffe, eben weil die DAC... puffern.

Viele dieser neueren Regeln stammen aus der Zeit, als wir sehr langsame "Fernleitungen" (2xISDN) hatten
und die Programme auch darüber laufen sollten (nur Dateninhalt, nicht EXE).

Dennoch würde ich mich wohler fühlen, wenn solche Netzwerkprobleme geklärt würden,
man weiß ja nie ...

[AUGE_OHR]

deine "Vorgaben" würde keiner schlucken, den ich kenne

klar haben die gemault ... bis zum 1st "grossen" Problem ... was Zeit und Geld gekostet hat.
so ähnlich wie bei der Datensicherung wo den Jungs der Streamer "zu teuer" war ...

wenn man sich die Hardware Preis ansieht ist ein Server "billiger" als wenn ich dauert hin muss,
also bekommen die einen Server den "ich" vorbereitet habe oder "die" kümmern sich selbst darum.

ich bin Programmierer, also Software, und habe keine Lust auf Hardware und deren Probleme.
Nur wenn ich die Maschine "kenne" kann ich ein Problem beurteilen und einer OEM installation
"traue" ich schon gar nicht ... ne, ne "das" mache ich doch lieber selbst und habe das unter
Kontrolle wenn ich die Wartung dafür übernehmen soll.

... da war doch mal ein Kunde der "selbst" die Backup Software installieren wollte. Alles schien
auch soweit zu laufen und der Steamer ist wohl auch zur vorgegebenen Zeit angelaufen.
Nun kam der Tag des grossen Desaster, also her mit dem Backup. Stolz präsentierte er mir dann
auch das "lates" Backup nur leider war es, wie auch die anderen Bänder, LEER ...

Tja installiert ist ja schön und gut, aber man sollte auch mal ausprobieren ob ein Backup wieder
einspielbar ist und die Daten auch wirklich "ok" sind ... ich hatte aber noch die *.DBF Daten als
ZIP von meiner letzten Wartung

Dennoch würde ich mich wohler fühlen, wenn solche Netzwerkprobleme geklärt würden, man weiß ja nie ...

klar und die einfachst ist "ständig" den Server mit Anfrage zu "beschäftigen".

ich hab ja mal ein kleines internes "Mail" Programm geschrieben weil mir das "NET SEND" zu
umständlich war. klar das eine DBF dahinter hängt und die muss ich ja nun regelmässig abfragen
ob es neue Mails gibt. Deshalb hatten auch schon meine Cl*pper Applicationen alle eine Timeout
Function wo ich dann solche Abfragen starten kann. Das selbe ist tut nun der 4th Parameter bei
AppEvent() der den xbe_None Event generiert.

Allerdings fragt er Mails nur alle 60sec. ab und für einige neuere Applicationen hab ich das selbe
Prinzip "Benachrichtigungen" nun so umgebaut das es "Mails" an die Application "selbst" sendet.
per Thread "pollt" die Appication dann den Server um nachzusehen ob es "Mails" für ihn gibt z.b.
:refreshAll() von einem Browse oder das Codejock Calendar activeX "updaten".

... und dann gibt es ja noch die "OP Locking & Netzwerkstabilität•Absolut-notwendig" Tips von
Steffen die beim Usertreffen präsentiert wurden ...

[Jan]

Ich muß da mal eine Frage in den Raum werfen: In wie weit betrifft das speziell Xbase++-Programme?

Warum ich die Frage stelle: Ich habe schon diverse Problemchen von Xbase++ gehört, wo man einfach den dahinterliegenden Rechner ein wenig umkonfigurieren muß. Was ich für eine Katastrophe halte. Klar müssen bestimmte Programme bestimmte Einstellungen haben. Aber mein Kunde wird mir was husten wenn ich dem sage: Dein Rechner ist einfach nur schlecht konfiguriert, deswegen hat mein Programm Probleme. Wenn nämlich alles andere bei dem Kunden läuft, dann ist nicht sein Rechner schuld sondern mein Programm. Bzw. die Programmiersprache, in der mein Programm geschrieben wurde.

Jan

[brandelh]

Hi,

laut einem Artikel von Alaska, der auf einen von M$ verweist, hat Microsoft die Zugriffe auf Dateien für Programme wie Word und Excel optimiert (große Datei einmal lesen/schreiben) und empfiehlt für die "alten" Programme die einzelne Dateisperren brauchen (DOS-Dbase etc. aber auch MS Access mit MDB oder Xbase++ mit DBF) modernere zu nutzen, die auf SQL Server (z.b. auch den frei erhältlichen mini Server von MS) für die Datenhaltung zugreifen. Diese haben das Problem grundsätzlich nicht, womit sich MS sicher erhofft hat, dass viele den teuren MsSQL Server kaufen (die freie Version ist noch nicht so alt ) und MS nix mehr in die lokale Dateihaltung von Access investieren muss ...

[AUGE_OHR]

Ich muß da mal eine Frage in den Raum werfen: In wie weit betrifft das speziell Xbase++-Programme?

es geht in Steffens 2nd Vortrag (für mich DAS Hilite ) beim Usertreffen nur um Xbase++

Dein Rechner ist einfach nur schlecht konfiguriert

die meisten Einstellungen sind ja für den Server gedacht, nur bei einigen muss man auch den Client "aktivieren".

... deswegen hat mein Programm Probleme.

JaNein ... denke mal an "Murphy" 1 von 10 Stationen macht "Probleme" und auf den 9 anderen läuft alles.

Genau das sind doch solche Situationen wo du den PC nur noch "platt" machen kannst und ein
Image von einer anderen Station (gleiche PCs) verwendest.

Wenn dann, bei "selber" Konfiguration, der PC nicht mit meiner Application läuft dann erst
hätte der Kunde "mir" bewiesen das es nicht an "seiner" Hardware liegt.

Ich bin eben nicht für "seine" Hardware zuständig, brauche aber für "meine" Application einen
Server den ich "traue". So kam man dann auf die 2 Server Lösung sodas man im Notfall auch
noch mit 50% arbeiten könnte.

Im Grunde ist der 2nd Server ja eh vom Kunden finanziert worden und steht bei ihm rum, aber
wenn es mit "dem" Probleme gibt dann bitte ich um einen Anruf damit "ich" mich darum kümmere.

so ähnlich wie "gelöschte Dateien" oder "formatierte HD" haben meine Kunden "gelernt" sofort
einen Profi zu fragen statt selbst irgendwelche Versuche zu starten die das ganze "verschlimmern"


was den 8.3 Tip gilt ja für den Client und müsste sich "global" auswirken (noch nicht getestet),
sodas alles "local" davon profitieren dürfte.

das natürlich alle Registry Einträge auch andere "Sachen" sich "gegenseitig" beinflussen ist klar,
deshalb ja auch 1x "reiner" *.DBF Server wo man möglichst auf allen "Schnickschnack" verzichtet
und alle "Dienste" abstellt die man nicht unbedingt braucht. Damit bekommt man, auch bei älterer
Hardware, solche "Bastelkiste" hin die als *.DBF Server richtig schnell sein können gegenüber
solchen "Boliden" die zwar massive Hardware besitzen aber auch massive "zugeschüttet" sind
mit etlichen Diensten und sonstigen Aufgaben ... PS gegen Gewicht wie in der Formel 1