upload großer dateien mit method=post auf mysql-datenbank

[red_or_dead]

hallo!

ich habe ein problem beim upload großer dateien. alle datein unter 1 mb kommen ohne probleme auf der datenbank an während größere nicht mehr auf der datenbank landen.

mein problem ist, dass ich nicht mal genau weiss, wo ich den fehler suchen soll. datenbank dürfte mit longblob-spalte nicht das problem darstellen.

bleibt der apache-server, perl oder der internet-browser selbst. gibt es irgendwo eine standardmäßige begrenzung, die man evtl. aufheben muss?

wäre für tipps sehr dankbar.....

gruss

philipp

[Helmut Weber]

Hallo Philipp,

generell halte ich es für Sinnvoller, wenn Du Dateien ganz normal im Filesystem ablegst, und nur eine Verknüpfung und eventuelle Datei-Informationen in der Datenbank ablegst.

Bei 1MB sehe ich eigentlich kein Problem beim Datei-Upload, wobei ich natürlich deine EInstellungen der oben genannten Komponenten nicht kenne.

Gruß
Helmut Weber

[Struppi]

hallo!

ich habe ein problem beim upload großer dateien. alle datein unter 1 mb kommen ohne probleme auf der datenbank an während größere nicht mehr auf der datenbank landen.

Du packst Dateien in eine Datenbank? Warum denn das? Dazu gibt es doch schon das Dateisystem, effektiv und schnell. Du weißt, dass DB Zugriffe über einen Server erfolgen, dass heißt die Daten würden erst übertragen werden müssen soweit der Server nicht zu sehr ausgelastet ist, während du auf Dateien sehr unmittelbar zugreifen kannst. Vor allem wenn es um Größenordnungen wie du sie hast geht.

mein problem ist, dass ich nicht mal genau weiss, wo ich den fehler suchen soll. datenbank dürfte mit longblob-spalte nicht das problem darstellen.

bleibt der apache-server, perl oder der internet-browser selbst. gibt es irgendwo eine standardmäßige begrenzung, die man evtl. aufheben muss?

Das einzige was mir einfällt ist der Server, die meisten Anbieter lassen für CGI Skripte nur ein begrenzte Laufzeit zu. Vielleicht dauert es zu lange, die Dateien in die DB zu schieben.

Struppi.

[rolfrost]

Mahlzeit ;-)

Du packst Dateien in eine Datenbank? Warum denn das? Dazu gibt es doch schon das Dateisystem, effektiv und schnell. Du weißt, dass DB Zugriffe über einen Server erfolgen, dass heißt die Daten würden erst übertragen werden müssen soweit der Server nicht zu sehr ausgelastet ist, während du auf Dateien sehr unmittelbar zugreifen kannst. Vor allem wenn es um Größenordnungen wie du sie hast geht.

Warum nicht in DB? Ein CMS wie zB zope speichert JEDEN Content-Type in einer DB.

Bitte nicht falsch verstehen, ich werbe nicht für zope (muss nur gelegentlich damit arbeiten...) aber ich sehe ein paar Vorteile für das Speichern von Dateien in einer DB:

Sicherheit

• da ists zB nicht mehr möglich Dateichen hochzuladen die im FS Schaden anrichten können.

Weiterverarbeitung

• Content UND Content-Type stehen in der DB, das bringt Vorteile wenn solche Dateien weiterverarbeitet werden sollen, zB. für den Mailversand: Die Daten liegen sozusagen griffbereit.
  Und wenn ich den Content-Type schon hab, kann ich auch gleich den richtigen header zum Browser senden, falls die Datei dahin folgen soll.

Attribute

• in einer DB können weitere Attribute bzw. Infos zur Datei abgelegt sein die im FS NICHT abgelegt werden können (Author etc).

Konsistenz

• der Record steht an EINER Stelle in der DB, es gibt also kein Konsistenzproblem zwischen einem Link in der DB und der physischen Datei.

Viele Grüße, Rolf

[Struppi]

Warum nicht in DB? Ein CMS wie zB zope speichert JEDEN Content-Type in einer DB.

Naja, ertsmal ging es um Dateien mit mindestens 1MB Größe und ich bezweifle das das effizient ist.

Bitte nicht falsch verstehen, ich werbe nicht für zope (muss nur gelegentlich damit arbeiten...) aber ich sehe ein paar Vorteile für das Speichern von Dateien in einer DB:

Sicherheit

• da ists zB nicht mehr möglich Dateichen hochzuladen die im FS Schaden anrichten können.

Du kannst die Dateien durchaus in Bereiche die nicht Zugänglich sind speichern und einfach mit...

print "Content-type....."

open FH, "dateiname"....
local $/, undef;
print <FH>
close FH;

wieder ausgeben. aber das sollte in der Regel nicht nötig sein.

Weiterverarbeitung

• Content UND Content-Type stehen in der DB, das bringt Vorteile wenn solche Dateien weiterverarbeitet werden sollen, zB. für den Mailversand: Die Daten liegen sozusagen griffbereit.

Da ich es so machen würde, das ich die Datei als Datei (wir reden vermutlich über Binäre Daten, bei Texten würde cih vermutlich auch die DB bevorzugen) abspeichere und in der Datenbank einen Schlüßel mit allen relevenaten Angaben abspeichere habe ich diese Daten ebenfalls.
Mir geht es nur um Binäre Daten (vor allem in der Größenordnung in einer DB)

Und wenn ich den Content-Type schon hab, kann ich auch gleich den richtigen header zum Browser senden, falls die Datei dahin folgen soll.

Das macht der Server für mich (wenn ich nicht den oben beschrieben Fall anwende).

Attribute

• in einer DB können weitere Attribute bzw. Infos zur Datei abgelegt sein die im FS NICHT abgelegt werden können (Author etc).

wie gesagt das speichere ich natürlich in der DB ab.

Konsistenz

• der Record steht an EINER Stelle in der DB, es gibt also kein Konsistenzproblem zwischen einem Link in der DB und der physischen Datei.

Da geb ich dir recht. Das muss natürlich geprüft werden und erfordert zusätzlichen Aufwand z.b. beim löschen eines Datensatzes.

Die Frage ist nur ob der etwas geringere Aufwand, die Unmmengen an größeren Zeitaufwand den der Server (Rechnezeit)  und der SQL Server (Datenübertrageung) benötigen, rechtfertigt?

So Diskussionen ich mitlllerweile schon ötfers gelesen, dass viele Webmaster den SQL Server übermaßen belasten ohne daran zu denken, das dadurch die Performance für alle User sinkt. Und wenn du sagst bei Zope ist das Standard wundern mich die Perfomranceeinbrüche bei vielen Hostern nicht.

Struppi.

[rolfrost]

hi Struppi,

Da ich es so machen würde, das ich die Datei als Datei (wir reden vermutlich über Binäre Daten, bei Texten würde cih vermutlich auch

sorry, das hab ich vorhin nicht erwähnt: Bei mir werden Dateien (egal welcher typ) in einer DB bas64_encoded abgelegt...

So Diskussionen ich mitlllerweile schon ötfers gelesen, dass viele Webmaster den SQL Server übermaßen belasten ohne daran zu denken, das dadurch die Performance für alle User sinkt. Und wenn du sagst bei Zope ist das Standard wundern mich die Perfomranceeinbrüche bei vielen Hostern nicht.

So isses! Und die meisten privaten Websites brauchen einen solchen Overkil gar nicht, weniger ist oft mehr... Aber im Intranet, wo auf einem gut bestückten Server 1..3 Domains liegen und außer HTTP und HTTPS nix weiter läuft - da sieht die Sache schon anders aus. Zumal in einem CampusNetzwerk vom Server bis zum Endgerät eine Bandbreite von 100Mbit/s gegeben ist. Da ist ein Upload schnell gemacht!

Viele Grüße, Rolf

[Klaus Mock]

Hallo,

mein problem ist, dass ich nicht mal genau weiss, wo ich den fehler suchen soll. datenbank dürfte mit longblob-spalte nicht das problem darstellen.
bleibt der apache-server, perl oder der internet-browser selbst. gibt es irgendwo eine standardmäßige begrenzung, die man evtl. aufheben muss?

Das bedeutet, daß Du die Verarbeitungskette nicht genau genug 'beobachtest'. Viele mögliche Fehlerquellen entziehen sich somit Deiner Kontrolle.

Du könntest beginnen, den gesamten Verarbeitungsprozess mitzuprotokollieren. Beispielsweise könntest Du im Script Meldungen in eine Logdatei schreiben, um zu sehen wo es hakt. Außerdem sollten alle Funktionen, die möglicherweise Fehlerhaft enden können (Dateizugriffe, Zugriff auf CGI-Parameter, DB-Zugriffe usw.) peinlichst genau mit Protokollinformationen versehen sein (auch nach Beendigung der Fehlersuche), wenn ein Fehler auftritt. Und damit meine ich mehr als "Ein Fehler ist aufgetreten".

Es wartet also ein ganzes Stück Arbeit auf Dich. Hoffe nicht auf eine schnelle Antwort wie etwa "Ach da mußt Du nur den oder den Parameter umdrehen, dann geht's".

Grüße
  Klaus