Willkommen bei Entwickler-Forum.
Seite 2 von 2 ErsteErste 1 2
Ergebnis 11 bis 16 von 16
  1. #11
    Zaungast
    Registriert seit
    05.03.2006
    Beiträge
    49

    Standard

    Hallo Leute,
    nach weiteren Tests hat sich gezeigt, das der Lösungsansatz über Strings nicht glücklich ist. Je größer der Inhalt der Blobfelder ist um so schneller schwindet die Performance.
    Also eigentlich doch unbrauchbar.
    Alle Datensatzfelder in ein einziges Blobfeld packen und dann per BlobStream übertragen ist auch ein grosser Aufwand, weil man ja die Längen der einzelnen Felder mit eintragen muss um dann beim Einlesen beim Client alles wieder auseinander zu pflücken.
    Also auch nicht grade einfach.

    Jetzt habe ich viel gelesen über DataSnap bzw. Multitier Anwendungen.
    Wie das aussieht scheint das ein guter Ansatz zu sein. Allerdings wäre das neu für mich.
    Wie denkt Ihr darüber ?

    Gruss Gerhard

  2. #12
    Forenheld
    Registriert seit
    26.02.2003
    Beiträge
    16.115

    Standard

    Würde jetzt sagen, dass das nicht viel ändert. Letztlich muss der Blob von A nach B transportiert werden.
    Des Weiteren würde mir Infos fehlen:
    - Wo schwindet die Performance
    - Mengengerüst. Gehen wir von 2 MB pro Blob aus und in welcher Zeit benötigt der Client wieviele davon?
    - Ein Performanceproblem kann doch nur beim Initialverteilen auftreten. D.h. ab einem Zeitpunkt sollen alle Blobinhalte auch auf den Clients sein. Da kann es sicher sein, dass die Verteilung dauert.
    - Der Datenaustausch im laufenden Betrieb sollte natürlich die Anwendung nicht lahmlegen. D.h. dieser findet mit Threads oder gar in einer anderen Anwendung statt (bsp. Startet die Replizierung mit dem Start des Clients). Fordert der Client nun ein Blob an, welches noch nicht da ist, so wird das halt vorgezogen. Auch die Übermittlung zum Server sollte mindestens threadgesteuert laufen
    Christian

  3. #13
    Stammgast
    Registriert seit
    24.10.2011
    Beiträge
    1.199

    Standard

    Mmh, also die Stringlösung scheint ja irgendwie unsauber umgesetzt zu sein, wenn sie immer langsamer wird.
    Arbeitest Du mit indizierten/sortierten Strings? Auch der Zugriff via FieldByName, .value und andere Varianten benötigen im Massenbetrieb auch unterschiedlich Laufzeit und sind mehr oder weniger empfehlenswert.
    Es kommt mir irgendwie so vor, als ob Du sehr kleinteilig da rumwurschtelst und selbst vielleicht nicht mehr den Überblick hast?

    Ich hab jedenfalls etwas den Faden verloren. Zum sortieren:
    Du hast eine Lösung, der nur die BLOB Felder für Dokumente fehlen?
    Wo ist das Problem, eine Tabelle im Server für Dokumente anzulgen, das Server BLOB Feld im Client zu laden und dann entweder auf Platte zu speichern mit Dateiverweis in der Tabelle oder alles wieder lokal in eine DB zu quetschen? Wenn Du nach dem Download die Datei gleich im Filesystem ablegst, kannst Du das auch gleich so stehen lassen und als Cache nutzen. (Dann fehlt natürlich etwas Zusatzlogik, die je File den Cachestatus überwacht und ggF. nachlädt- was aber ja sowieso irgendwie kontrolliert geschehen muss...)

    Mit SQLite könntest Du serverseitig auch ein Programm anlegen, dass Differenzmengen in einzelne SQLlite DB je User verpackt und die dann nur runterladen zum Client und dort mit der vorhanden DB attachen (extra Befehl in SQLlite SQL) und von runtergeladener Differenzmenge zum lokalen Bestand inserten oder updaten.

    Meine Delphizeiten sind schon etwas her, schau mal auf Delphipraxis.net (siehe auch Link im vorigen Post), da gibt es sehr viele Ansätze zu dem Thema.
    Gruß, defo

  4. #14
    Zaungast
    Registriert seit
    05.03.2006
    Beiträge
    49

    Standard

    Hallo Christian, hallo Defo,

    Die Übermittlung der Daten vom Server zum Client ist wohl nicht threadgesteuert, weil ich dachte, das TIdTCPServer schon threadgesteuert arbeitet.
    Insofern ist das ein Grund, warum es länger dauert.
    Der Hauptgrund aber liegt wohl in der eigenen Routine, die die Stringliste verschlüsselt und am Client wieder entschlüsselt..
    Je länger die Stringliste ist um so länger dauert es bis die verschlüsselte Stringliste gesendet wird.
    Insofern hat defo wohl recht, das die Implementierung zur Zeit nicht grade sauber gelöst ist.
    Desweiteren werden die Komponenten, die pro Anfrage benötigt werden nicht in einem Thread erzeugt sondern werden zentral bei der Anfrage erzeugt und nach Abschluss der Übertragung wieder frei gegeben. Kommt dann in der Zeit eine weitere Anfrage, dann muss die Anfrage warten bis die Komponenten wieder freigegeben sind.
    Da bisher nur kleine Stringlisten übertragen wurden fiel das nicht so genau auf. Aber jetzt bei grossen Stringlisten macht sich das bemerkbar.
    Daher habe ich etwas umgebaut.
    Wenn in einer Tabelle ein Blobfeld gefunden wird, dann überträgt der Server dieses Feld über einen Blobstream, was wesentlich schneller geht.
    Da die Tabellen im Server und im Client gleich strukturiert sind, weiss der Client also das er einen Blobstream für das Feld erhält.
    Was zur Zeit wohl dann noch fehlt ist die Verlegung der Anfragen in einen Thread denke ich.

    Defo, das Programm ist schon älter. Insofern muss ich den Programmcode noch genauer durchgehen, warum das damals so entwickelt wurde.
    Im Dateisystem die Inhalte der Blobfelder abzulegen war eine Idee, die aber vom Kunden abgelehnt wurde.
    Da die User einfach den Client und die SQLite-Datei kopieren, wenn sie von einem Computer zum anderen Computer umziehen, wollen die auch nicht noch eine Dateistruktur von der Festplatte mit kopieren. Das verstehe ich gut. Daher muss ich die Daten in Blobfelder ablegen.

    Es gibt eine zentrale Tabelle auf dem Server, wo alle Änderungen pro Tabelle per Timestamp protokolliert werden.
    Diese Tabelle wird vom Client angefordert und gelesen und die Unterschiede mit der eigenen zentralen Tabelle heraus gefiltert.
    Dann werden die geänderten Datensätze pro Tabelle zwischen dem Server und dem Client übertragen.
    Je weniger Datensätze geändert wurden um so weniger muss zum Client übertragen werden.
    Da aber die Protokollierung der Änderungen nur pro Datensatz und nicht pro Datenfeld implementiert ist. muss der ganze Datensatz, wenn der geändert worden ist, übertragen werden.
    Kommen nun die Blobfelder noch dazu, dann braucht das eben mehr Zeit.

    Da habe ich wohl noch ein bißchen Arbeit vor mir um den Abgleich der Daten sauber und besser zu implemetieren.
    Stellt sich die Frage, wie threadsicher TIdTCPServer ist...

    Gruss Gerhard

    P.S.

    Ein User hat heute eine PDF-Datei abgelegt mit jeder Menge Graphiken. Größe ca. 25 MB...
    Jetzt fragt der Kunde ob man auch die Office Datei direkt ablegen kann... damit ein andere User die weiter bearbeiten kann...
    Also scheinen die User das nun als Dateitransfer benutzen zu wollen anstatt per Mail zu versenden wie vorher...
    Geändert von Gerhard Wascinski (30.12.2016 um 11:15 Uhr)

  5. #15
    Stammgast
    Registriert seit
    24.10.2011
    Beiträge
    1.199

    Standard

    Nun ja, bei solchen "Verfahren" muss man dann wohl doch auch Fragezeichen machen?
    25MB sind 25MB, die übertragen werden müssen. Das ist mit schlechter Datenleitung schon eine kleine Qual.
    Wenn das dann noch schlecht umgesetzt ist, sind es 25 MB plus viel Overhead.

    Schlecht komprimierte Bilder oder ungeeignete Bildformate oder Kompressionsverfahren in Word oder PDF oder wo auch immer sind dann ebenfalls problematisch. Da kann aber vielleicht auch etwas über die Einstellungen in Word oder PDF geregelt werden.

    Das Ganze dann noch redundant als Arbeitsversion in Word und PDF macht es nicht besser.
    Und wenn die Mitarbeiter sowieso manuell Dokumente hin und her schieben, warum dann noch mal in einer DB?

    Wenn dann noch in einem Datensatz ein Flag geändert wird und sei es nur ein Änderungsdatum, dann noch gleich den ganzen BLOB Inhalt wieder übertragen macht auch keinen Sinn oder?

    Nochmal, mir scheint das alles sehr kleinteilig und letztlich nicht mehr zeitgemäß.
    Für Dateisynchronisierung gibt es mittlerweile viele Angebote, auch kostenlose. Z.B. owncloud oder Konkurrenz.
    Für Datensynchronisierung / Replikation ebenfalls (jenachdem welche Infrastruktur da ist)
    Gruß, defo

  6. #16
    Zaungast
    Registriert seit
    05.03.2006
    Beiträge
    49

    Standard

    Die Applikation ist sicherlich nicht mehr so zeitgemäß wie sie mal war.
    Anforderungen steigen jedes Jahr.
    Daher verhandele ich grade mit dem Kunden etwas neues zu entwerfen auf Basis neuer Strukturen und Komponenten.
    Datasnap ist eine Variante. Zertifikate werden wahrscheinlich auch gebraucht, was die Sache nicht einfacher macht.
    Mittlerweile hat fast jeder ein Smartphon. Spätestens dann platzt die alte Programmversion, da auf Smartphones kein Platz für Dokumente ist.
    Mal schauen was der Kunde bereit ist zu investieren. Anderfalls muss er eben mit dem leben was er hat, oder einen andere Firma suchen, smile.....

    Gruss Gerhard

 

 
Seite 2 von 2 ErsteErste 1 2

Stichworte

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •