SMB1 und Dateizugriff-Schweinkram

Konzeptionelles, Technisches, Termine, Fragen zum Hersteller usw.

Moderator: Moderatoren

Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 13488
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Kontaktdaten:

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von Jan » Fr, 13. Jul 2018 16:39

Ich denke mal wir sind uns in dem Punkt einig, das Xbase++ zwar ein ordentliches Werkzeug ist, mit dem man ordentliche Anwendungen schreiben kann. Und in manchen Punkten auch herrausragend ist. Aber insgesamt dem Markt arg hinterher hinkt. Wobei sich natürlich immer die Frage stellt: Brauch ich wirklich mehr, oder komm ich damit aus? Man muß ja auch nicht immer mit Kanonen auf Spatzen schießen, wenn die Flinte hervorragend ausreicht.

Das Argument, das auch die 2.0 bereits ein paar Jahre auf dem Buckel hat (halt sechs), zählt für mich nicht ganz so sehr. Denn wenn eine Firma auf CD umstellt, dann gibt es halt nicht mehr diese Versionssprünge im Monats- oder Jahresrhytmus. Selbst große Firmen machen das inzwischen so, siehe Windows 10. Das auch mehr Jahre als alle Versionen vorher auf der gleichen Versionsnummer stehen bleiben wird. Den Fortschritt sieht man nicht in der Versionsnummer sondern im Build.

Ich selber habe damit übrigens ein interessantes Problem: Meine Software war vor 2 oder 3 Jahren auf einer Pearl-CD. Die möchten mich für ende diesen jahres gerne wieder dabei haben. Geht aber nicht. Regel bei denen ist, niemals die gleiche Version noch einmal zu veröffentlichen. da ich aber schon seit 10 Jahren mit CD arbeite, die Versionsnumemr nur bei eklatanten Erweiterungen steigt, habe ich immer noch die gleiche Hauptnummer wie damals. Und nur wegen Pearl werde ich das nicht durchbrechen. Bin ich halt raus. Ich trauere da nicht allzu viel drum, den Schub hat das in den Verkaufszahlen dann auch nicht gebracht. Aber schon bezeichnend, das die Firmen oder verantwortlichen an Dingen festhalten, die höchstens Bauchgefühl, Unwissenheit, oder Werbestrategie sind. Aber real keinerlei Bedeutung haben.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12040
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von AUGE_OHR » Fr, 13. Jul 2018 18:48

war klar das es auf so eine Diskussion raus läuft statt sich ans Thema zu halten ... :roll:

> Die normale Sharerei ist um den Faktor 100-400 schneller

@Mike : schon mal getestet wie "langsam" Windows wird wenn SMB abgeschaltet ist :?:
gruss by OHR
Jimmy

Benutzeravatar
Rudolf
Programmier-Gott
Programmier-Gott
Beiträge: 1418
Registriert: Mo, 02. Jan 2006 23:03
Wohnort: Salzburg/Österreich
Kontaktdaten:

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von Rudolf » Sa, 14. Jul 2018 6:51

Hallo,
Tom: danke, genauso sehe ich es, vor allem mit dem technologischen Stand von xBase++. Jeder der sich für seinen Weg entschieden hat, hat seine Gründe. Und ich würde nie deshalb andere als weniger kompetent oder fahrlässig bezeichnen ohne die Gründe zu verstehen. Damit hoffentlich wirklich beendet ;-)
Jimmy: auch danke, wir sind wieder beim Thema ;-) Für mich ist das Maß für die Geschwindigkeit der Aufbau meiner komplexen Dialoge. Mir ist egal wie lange ein Index oder Pack dauert, das wird sowieso nur sehr selten verwendet, und dann kann ich die Zeit planen.
Grüße
Rudolf

Benutzeravatar
mikehoffmann
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 109
Registriert: Mo, 21. Sep 2015 16:22

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von mikehoffmann » Sa, 14. Jul 2018 11:23

@Jimmy: Nee. Mir reicht, was ich gesehen habe.

Mit ein paar weiteren Experimenten SET EXCLUSIVE ON/OFF und skippen mit und ohne Datenzugriff sieht man sehr schön die Optimierungsmechanismen der DB-Engine und wie die manchmal sauber in die Binsen gehen. Aber die Bottomline ist schon, dass wir die hohe Geschwindigkeit unserer Applikationen dem Betriebssystem / SMBx zu verdanken haben. Wenn da was gedreht würde, wäre schnell Schluss mit lustig.

Ich habe auch den Eindruck gewonnen, dass die Anzahl der Anfragen an den Server das entscheidende Mass für die Geschwindigkeit ist. Die nachfolgenden Tests wurden wieder per Loopback gemacht.

1. Summe aller buyprices im shared mode der 1500 Sätze in der cars.dbf ohne Index: 2,97 Sekunden, 1541 Anfragen, 266KB Antwortdatenvolumen.

2. Summe aller buyprices im shared mode der 1500 Sätze in der cars.dbf mit Index: 13,6 Sekunden, 7550 Anfragen, 2,160MB Antwortdatenvolumen.

Der Testfall 1 zeigt auch sehr klar, wo die Grenzen für Phils DBFSERVER liegen. Denn schneller als das kann auch er nicht.

Sehr unschöne Ergebnisse.

Wenn ich das richtig interpretiere, würde ich folgende Schlüsse ziehen:

Solange ein Anwender sich satzweise durch die Daten hangelt und diese vielleicht auch ändert, ist die dbf-Philosophie weiterhin brauchbar. Sobald mehrere Sätze betroffen sind (sowohl lesend als auch schreibend), sollten die erforderlichen Operationen ausschließlich auf einem Server durchgeführt werden. So ein Code in unseren Programmen:

GO TOP
DO WHILE .NOT. EOF()
summe += FIELD->buyprice
SKIP 1
ENDDO

geht dann gar nicht mehr. Und da fällt das Kartenhaus der Hoffnung zusammen, alten Code einfach in die Zukunft portieren zu können. Diese Code-Strecke müsste an den Server zur Ausführung gesandt werden. Helm ab zum Gebet.

Man könnte das aber auch als Chance sehen.

Michael

ramses
Programmier-Gott
Programmier-Gott
Beiträge: 1446
Registriert: Mi, 28. Jul 2010 17:16

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von ramses » Sa, 14. Jul 2018 12:26

Hallo Michael

das Kartenhaus braucht nicht zusammenzubrechen. Es gibt noch den ADS-Server.
Damit kannst du die DBF ohne auswirkungen von SMB und grosse Code-Anpassungen im Client-Server Betrieb bearbeiten.
Auch die von dir erwähnten Schlaufen sind möglich-
Nicht ganz so schnell wie die DBFNTX aber absolut zuverlässig und auch mit Verschlüsselung der Daten.

Oder wenn du Geschwindikeit pur möchtest dann Postgres nativ das stellt dann alles in den Schatten bedingt aber grosse Umbauten am Code.

Gruss Carlo
Valar Morghulis

Gruss Carlo

Benutzeravatar
mikehoffmann
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 109
Registriert: Mo, 21. Sep 2015 16:22

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von mikehoffmann » Sa, 14. Jul 2018 13:11

Hallo Carlo,

ADS scheidet für mich aus. Das hat sehr rationale und sehr irrationale Gründe. Dennoch habe ich in Folge meiner Erkenntnisse ein wenig zum Thema ADS rumgegoogelt. Was ich gesehen habe, hat beide Grundkategorien in der Intensität gesteigert.

In meinem Kopf wächst im Moment ein ganz neues Pflänzchen, das diese Probleme beheben kann und noch ganz andere Chancen bietet. Stell Dir vor, Du schreibst Code, der zwar (pro Thread) sequentiell abläuft, das aber auf verschiedenen Rechnern tut. Und ich rede hier nicht von verschickten Codeblöcken oder Macros, sondern vom gleichen ausführbaren Code, der auf allen teilnehmenden Restaurants, nee Rechnern natürlich, vorliegt und ausgeführt wird.

Viele Grüße
Michael

ramses
Programmier-Gott
Programmier-Gott
Beiträge: 1446
Registriert: Mi, 28. Jul 2010 17:16

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von ramses » Sa, 14. Jul 2018 16:45

Hallo Michael
Was ich gesehen habe, hat beide Grundkategorien in der Intensität gesteigert.
Verstehe voll und ganz. Wir verwenden den schon seit vielen vielen Jahren... Seit dem letzten Besitzerwechsel ist es noch ein "Notnagel" keine Neuinstallationen mehr. Mein Ziel ist weg von ADS der komplette Umbau der Programme auf Postgres mit Browser basierender Oberfläche.

Deine "Pflänzchenidee" ist nicht ohne. Bedeutet dann auch dezentrale Datenbestände was viele Probleme lösen würde. So lange diese nicht zu gross werden. Synchronisiert nach dem Blockchainsystem .... Muss auch mal darüber nachdenken.

Gruss Carlo
Valar Morghulis

Gruss Carlo

Benutzeravatar
mikehoffmann
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 109
Registriert: Mo, 21. Sep 2015 16:22

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von mikehoffmann » Sa, 14. Jul 2018 18:17

Hallo Carlo,

über so wildes Zeug wie Block-Chain Sachen denke ich nicht nach. Mir geht's nur drum, den Code da laufen zu lassen, wo es am günstigsten ist. Mit der genannten Lauf-Verteilung kriegt man das konkrete Problem und eventuell noch ein paar mehr in den Griff. Außerdem hängt man nicht von Anfang an am Detail der DBF-Problematik. Die kriegt man am Ende non-chalant hin. Hoffentlich zumindest.

Zu stellende Frage: Kann man feststellen, wo eine Code-Strecke am besten läuft? Sagen wir mal ja, in Extremfällen kann der Programmierer ja noch mitwirken. Aber diese DO WHILE .NOT. EOF() Dinger oder andere Schleifen mit SKIPs oder GOTOs oder SEEKs sollte man schon mit einem Preprozessor erkennen können. Mit dem verschiebt man den Schleifenkörper in eine eigene Funktion (im gleichen Modul) und ändert den Code so, dass alle im Schleifenkörper verwendeten Variablen Parameter der Funktion werden. In den Original-Code wird dann einfach der Aufruf dieser Funktion reingesetzt. Fertig. Damit würde das Progrämmchen erst mal tickern wie vorher.

Wenn nun derselbe Code (also auch die Substitions-Funktion) auf einem entfernten Rechner zur Verfügung stünde, müsste man nur die Parameter rüberschaukeln und den Code da ausführen. Wenn das der Server wäre, könnten plötzlich alle Client-Killer-Programmteile auf dem Server laufen.

Jetzt höre ich schon wieder alle rumschreien, so einfach wäre das nicht. Dann bitte ich doch mal um Nennung von konkreten Problemen. Einige fallen mir auch gleich ein, aber mit etwas Einschränkung keine, die nicht lösbar wären.

Viele Grüße
Michael

ramses
Programmier-Gott
Programmier-Gott
Beiträge: 1446
Registriert: Mi, 28. Jul 2010 17:16

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von ramses » Sa, 14. Jul 2018 20:05

Hallo Michael

mit einer Web-App hättest du ja genau das.
Die ganzen goto's skip's usw, laufen alle auf einem Server.
Du sendest vom Browser über https Anforderungen an den Server, auf diesem läuft den Code, erstellt die Antwort und sendet diese Zurück.
Die Möglichkeiten um Masken im Browser darzustellen sind beinahe unbegrenzt. es gibt viele viele Add ons in JS die du verwenden kannst.
Xb2Net als Web-Server in Xbase ist ein guter Einstieg für Web-Apps. Du brauchst kein Apache oder IIS deine EXE ist alleine der Webserver.

Anstelle von Code-Teilen zum erreichen besserer Leistung zur Ausführung auf einen anderen Rechner zu senden sehe ich den Weg eindeutig beim Umstieg auf Postgres. Die DBF basierenden Datenbanken können mit der Performance von Postgres in keiner Weise mithalten.
Die grösste Postgres Datenbank mit der ich arbeite hat momentan 535'000'000 Datensätze hier einige Sätzte zu suchen was bei DBF's z.B. einem set filter to entspricht dauert ca. 0,1 Sek. Das Ergeniss sind einige 100 Datensätze ich finde dies zeigt eindrücklich dass es für DBF's Grenzen gibt wenn man diese erreicht ist der bessere Weg vermutlich schon die Datenbank zu wechseln. Leider bleibt uns der einfachste Weg dies zu tun, einfach die DBE zu tauschen wie uns Alaska lange versprach, verschlossen. Die Alaska PGDBE versagt hier komplett.


Gruss Carlo
Valar Morghulis

Gruss Carlo

Benutzeravatar
Rudolf
Programmier-Gott
Programmier-Gott
Beiträge: 1418
Registriert: Mo, 02. Jan 2006 23:03
Wohnort: Salzburg/Österreich
Kontaktdaten:

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von Rudolf » Sa, 14. Jul 2018 21:02

Hallo Carlo,
also mich nervt es in der Zwischenzeit sehr dass Du ständig jeden mit Deinem Weg missionieren willst. Es gibt auch andere Wege und Meinungen, hier gehts um die Lösung von Michael, jede andere Diskussion sollte in einem anderen Thread laufen denke ich. Es wird sonst wirklich mühsam. Sorry, das musst ich mal loswerden.
Grüße
Rudolf

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12040
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von AUGE_OHR » Sa, 14. Jul 2018 21:06

hi Carlo,

die 2GB DBF Grenze ist natürlich DER Grund auf SQL zu wechseln.

---

Das Problem der Entwickler ist der vorhandene Source Code der User

Code: Alles auswählen

   DO WHILE !EOF()
      IF Bedingung()
         AAdd( aArray, RecNo() )
      ENDIF
      SKIP
   ENDDO
das wäre eine normale xBase Schleife die hier aus 6 Zeile besteht.

mit der ISAM Emulation von PgDBE läuft so ein "normaler" Code mit WHILE !EOF() und SKIP extrem langsam.
nun wird es auch mit der native Version nicht viel schneller wenn man solchen Source Code übernimmt ... [-X

man muss schon anderen Code schreiben/optimieren.
wenn ich nun solchen Source Code vorliegen hätte

Code: Alles auswählen

   DbEval( {|| AAdd( aArray, RecNo() ) } , Bedingung()  ) 
könnte man daraus dann das in SQL machen

Code: Alles auswählen

   SELECT * FROM ABC WHERE Bedingung()
ein Pre-Prozessor müsste also die "Bedingung erkennen" und die ganze DO WHILE Schleife "auflösen".
ob man solchen Code per Pre-Prozessor erzeugen kann :idea:
... besser wäre es wohl wie bei Express++ mit eigener Syntax.

p.s. der Demo-Code ist nicht auf Syntax geprüft sondern dient nur der Verdeutlichung der Idee :!:
gruss by OHR
Jimmy

ramses
Programmier-Gott
Programmier-Gott
Beiträge: 1446
Registriert: Mi, 28. Jul 2010 17:16

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von ramses » Sa, 14. Jul 2018 22:31

Hallo Rudolf

"Missionieren" geht anders. Ich habe einen Teil unserer Erlebnisse und Erfahrungen mit euch geteilt. Dank diesen Erkenntnissen und den daraus gezogenen Veränderungen konnten wir überleben. Auch andere User hier haben mit Sicherheit auch schon Kunden an andere Anbeiter mit Web-Apps verloren. Wenn dich das derart nervt gut. Kann ich aktzeptieren und schweigen.

** Dies war mein letzter Beitrag zu diesem Thema **

Gruss Carlo
Valar Morghulis

Gruss Carlo

Benutzeravatar
Rudolf
Programmier-Gott
Programmier-Gott
Beiträge: 1418
Registriert: Mo, 02. Jan 2006 23:03
Wohnort: Salzburg/Österreich
Kontaktdaten:

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von Rudolf » So, 15. Jul 2018 8:11

Hallo Carlo,
das Thema ist ja berechtigt, aber bei jedem andren Thema damit wieder zu beginnen ist für mich das Problem. Wieso machst Du nicht einen eignen Thread in dem es nur um dieses Thema geht ?
Grüße
Rudolf

Benutzeravatar
mikehoffmann
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 109
Registriert: Mo, 21. Sep 2015 16:22

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von mikehoffmann » So, 15. Jul 2018 11:04

@Carlo:

selbstverständlich kann man auf eine SQL-Server-basierte Lösung umstellen. Danach hast Du aber ein anderes Programm und eine andere Philosophie. Mir stellt sich da zwangsläufig die Frage, ob ich nicht gleich meine Insel verlasse und ans Festland wechsle, wenn ich sowieso schon so lange schwimmen muss. Andere Inseln des Galapagos Archipels scheiden natürlich aus.

Das schließt natürlich nicht aus, dass ich z.B. den Postgres-Server verwende, wenn ich ihn brauche. Ich würde aber nie daran denken, ihn als Ersatz für dbf-Tabellen zu nehmen. Wir haben das intern untersucht und nach Sachlage irgenwann beschlossen, das Thema nicht weiter zu verfolgen. Diesmal nur aus rationalen Gründen.

Da ich kein Problem damit habe, einen Server zu schreiben, ziehe ich den Weg der Eigenentwicklung vor. Ob ich den Kommunikations-Stream pur von Socket zu Socket schicke oder ob ich mich auf ein Protokoll aufschalte (https, ...) ist mir dann schnuppe. Außer es geht um Geschwindigkeit, dann gilt "lean is mean" und das muss ich beherrschen.

@Jimmy:

Es gibt, denke ich, eine endliche Anzahl Schlüsselworte, anhand derer man eine Codestrecke automatisch erkennen sollte, die besser auf einem anderen Rechner läuft. Dass das mit dem Xbase++ Preprozesser nicht gehen wird, liegt schon daran, weil der nur einzelne Statements bearbeiten kann. Außerdem denkst Du schon gleich wieder im konkreten Problem. Das versuche ich noch zu vermeiden.
Was das DBF-2GB-Problem angeht, so ließe sich dies mit meinem Ansatz lösen. Der Workarea-Status wäre nämlich etwas, was zwischen den Rechnern ausgetauscht werden müsste.

@Alle:

Meine Perspektive ist: Ich habe ein Programm, das verteilt auf mehreren Rechnern laufen kann. Wo es läuft, hängt am Ende davon ob, welche Rechner zur Verfügung stehen. Die Verteilung kann großteils automatisch erfolgen, aber der Programmierer kann das natürlich auch bestimmen.

Jetzt geht es darum, rauszufinden, an welchen Gegebenheiten dieses Konzept scheitern könnte, welche Grenzen ihm gesetzt sind, wo man damit noch tierisch punkten könnte oder ob es angesichts der aktuellen Bedrohungslage eine kompletter Schmarrn ist, über sowas überhaupt nachzudenken.

Schönen Sonntag
Michael

Antworten