Grosse Dateien mit ADS in Blobfeldern ablegen dauert ewig

[adrian4321]

Hi, ich habe folgenden Code zum Speichern von Dateien in einem BLOB Feld einer ADS-Tabelle:

Delphi-Quellcode:

tbl_bak.AppendRecord([files[i]]);
tbl_bak.Edit;
(tbl_bak.Fields[1] as TBlobField).LoadFromFile(files[i]);
tbl_bak.Post;

Das mache ich so in einer for ... to Schleife so lange wie Dateien in "files" stehen. Funktioniert einwandfrei und schnell wenn die Dateien klein sind, aber bei ca. 70 MB grossen Dateien dauert es ca. 3 Minuten bis diese Datei gespeichert wurde. Die CPU klebt bei 100% und es erfolgt gemaessigter Plattenzugriff auf dem Laufwerk aus dem gelesen wird. Das zu beschreibende Laufwerk mit der Tabelle tut solange nichts. Folgen darauf wieder kleine Dateien, so geht es wieder schnell weiter.

Hat jemand eine Ahnung warum die grossen Dateien derart viel Zeit benoetigen??

ciao,
adrian

[Union]

Hallo,

die grossen Dateien benötigen so viel Zeit, weil viele Daten übertragen werden müssen. Wie lange dauert denn das Kopieren einer solchen Datei im Netzwerk? Ich habe mal einen Test mit ADS gemacht und habe folgende Ergebnisse:

Anzahl Dateien = 73
Bytes = 241,710,203
Dauer = 205436 ms

Also für 230 MB ca 3,5 Minuten. Wenn Du die Anwendung nicht während des Kopierens blockiert haben möchtest, musst Du eine eigene Routine schreiben, die die Daten immer blockweise anhängt und dann Application.Processmessages aufruft. Dann musst Du aber auch den BlobStream selber erzeugen und eine Variante von CopyFrom.

[adrian4321]

Hi,

ich merke ich habe meinen Fall noch nicht ausreichend beschrieben.... Ich benutze den Local Server von ADS, Netzwerkengpaesse fallen also definitiv weg und das normale Kopieren einer 70MB Datei ist auf dem Rechner eine Sache von ein paar Sekunden, nicht 3 Minuten.

Die Dauer scheint auch sozusagen exponentiell zur Datenmenge zu steigen, nicht doppelte Datenmenge > doppelte Zeit.

Ich habe einiges abgesucht ob vielleicht die Local Server Variante schuld ist, konnte aber nichts ueber irgendwelche Einschraenkungen in der Performance finden.

[Union]

Hallo,

ich habe jetzt auch mal einen Test mit dem Local Server gemacht. Dort ist der Vorgang sogar noch 10% schneller:

Zitat von Project1:

Imported 73 files (Remote) with 241.710.203 bytes in 214062 ms
Imported 73 files (Local) with 241.710.203 bytes in 193062 ms

Mir der "exponentiellen" Steigerung der Dauer abhängig von der Grösse hast Du allerdings in etwa recht - hier eine Aufstellung der größten Dateien mit Dauer und Geschwindigkeit:

Code:

Item filesize   seconds    BytePerSec
-------------------------------------
   1   61591350        106     581050
   2   28862268         25    1154491
   3   23295880         15    1553059
   4   21686968         13    1668228
   5   12426520          4    3106630
   6    9985463          2    4992732
   7    9870344          2    4935172
   8    9031773          2    4515887
   9    7506150          1    7506150
  10    7456731          1    7456731
  11    7371352          1    7371352

[adrian4321]

Hmm, allzuweit entfernt liegen unsere Ergebnisse ja nicht.... Ich habe just for fun den Test mit einer 600MB Datei gemacht -- und dann nach 4 Stunden abgebrochen Daraufhin habe ich Extended Systems eine Mail mit der Beschreibung geschickt (echt fix die Jungs, Antwort ist schon da....), und sie wuerden gerne meine Anwendung bei ihnen testen.

Mal sehen was da raus kommt!

ciao,
adrian

[Union]

ooops, ich habe ihnen meine Ergebnisse auch geschickt. Wozu verwendest die Routine eigentlich? Was speicherst Du dort - Backup-Daten oder was? Evtl. wäre es interessant den Stream durch einen Kompressor laufen zu lassen, wenn die Daten komprimierbar sind (z.b. Abbrevia).

[adrian4321]

Genau, das Programm packt alle Daten ab einem waehlbaren Verzeichnis inkl. der Dateien in den Unterverzeichnissen in die Tabelle. Besonders die einfache 160 Bit Verschluesselung hat mich da gereizt.... Habe sie aber als erstes bei der Fehlersuche wieder deaktiviert.

Dass das normal ist mit der extremen Dauer von grossen Dateien kann ich mir nicht vorstellen - schliesslich duerfen die BLOBS bis zu 4GB gross werden.

Das Paket an den ADS Support ist jedenfalls gerade raus gegangen, jetzt mal abwarten.

ciao,
adrian

[adrian4321]

Der schnellste und beste Support den ich kenne *g*

Zitat:

ich habe mir Ihr Programm angeschaut und getestet. Im Moment vermute ich, dass die Files die in ein BLOB-Feld gespeichert werden sollen erst einmal im Hauptspeicher geladen werden um dann in die Tabelle geschrieben werden zu können. Je größer das entsprechende File ist umso länger dauert dies. Allerdings ist das - wie eingangs schon erwähnt - eine Vermutung. Ich werde bei uns in der Entwicklung nachhaken, ob es sich tatsächlich so verhält. So bald ich die Information habe werde ich Ihnen diese weiterleiten. Da unsere Entwicklung in den USA ist kann das allerdings ein bißchen dauern (Zeitverschiebung).

Ich werde Euch auf dem Laufenden halten!

[Union]

Es sieht so aus, dass es daran liegt, dass ADS die Blobdaten cached. Dieses Verhalten läßt sich auch nicht abschalten. Die einzige Möglichkeit wäre wahrscheinlich, direkt über AdsSetField zu gehen. Aber sehr viel overhead schaltet man damit auch nicht aus.

So geht es (Post und Edit sind wichtig, weil man sich sonst den Recordcache durcheinanderbringt!):

Delphi-Quellcode:

sFileName := Path+sr.Name;
tblBackup.Post;
tblBackup.AdsFileToBinary(tblBackupFileData.FieldName , btBINARY, sFileName);
tblBackup.Edit;

Ergebnis

Code:

Blobtest
---------------------------
Imported 73 files (Local) with 241.710.203 bytes in 23030 ms
---------------------------
OK   
---------------------------

Also eine fast 10-Fache Geschwindigkeitssteuerung!

[adrian4321]

Stimmt, mit dem Befehl klappts wunderbar schnell! Der ADS Support schrieb mir heute folgendes von seinem Kollegen in USA:

Zitat:

Yes, the entire file will be loaded into the memory.

There is an ACE API call that can save the file in chunks; however, I am not sure that this is the type of solution you are looking for.

@Union: Teilst Du das dem Support ([e-mail]) mit oder soll ichs machen?

ciao,
adrian