Tach!
Wie schon gemutmaßt, auch der Webserver hat Begrenzungen. Je nach Konfiguration auch mehrere. Beispielsweise hat der Apache auf alle Fälle eine und wenn PHP als FCGI eingebunden ist, dann hat auch das FCGI-Progamm eine.
Das hatte ich nicht erwartet! Ich habe aber schon einiges gefunden:
FcgidMaxRequestLen(PHP-FCGI), FcgidBusyTimeout(PHP-FCGI), LimitRequestBody(Apache)
Genau sowas. Je nach FCGI-Programm heißen die Konfigurationswerte auch anders.
Die Gesamtgröße spielt keine Rolle mehr, wenn jede Datei mit ihrem eigenem Request verarbeitet wird.
Diesen Satz weiss ich nicht so richtig zu deuten. Klar, für 10 HTTP-Uploads á 100MB werden die Konfigurationen für 100MB vorgenommen werden müssen und nicht für 10*100MB.
Wenn dir das schon klar ist, dann ist gut. Du hattest nur drei Postings vorher die Rechnung aufgemacht 10 × 100MB = 1GB. Darauf bezog ich mich.
Richtig, hatte ich auch. Weil ich bis vorhatte, ein Formular mit 10 input[type=file] zu bauen. Das wären dann 10 * 100MB = 1GB. Wenn es irgendeinen Vorteil hat (bspw. dass ich dann nur die Konfigurationsparameter in der php.ini ändern muss), das ganze auf 10 Formulare, also 10 Requests aufzuteilen, würde ich das tun.
Meinst Du damit, für 100MB werden keine aussergewöhnlichen Anpassungen der Konfiguration vorgenommen werden müssen?
Doch, doch, 100MB ist jenseits der Default-Werte. Die liegen bei wenigen MB.
Ich hatte ja ursprünglich geplant, die Files nach dem Upload und einer Validierung direkt im upload_tmp_dir per ftp_put() auf einen anderen Rechner zu verschieben um zu vermeiden, dass ich sie Files noch irgendwo zwischenlagern muss. Wenn Du sagst, ein Background-Prozess wäre angebracht, nehme ich das so an.
Das musst du selbst entscheiden. Wenn der FTP-Transfer auch bei großen Dateien unmerklich flott läuft, dann brauchst du keine Zwischenlagerung.
Nur zum Verständnis: Ein Cronjob würde es erforderlich machen, die hochgeladenen Files aus dem upload_tmp_dir woanders hinzukopieren, oder? Denn nachdem das Script, dass den Multipart-Request en Empfang nimmt, sind abgearbeitet ist, werden sie irgendwann aus dem uolaod_tmp_dir gelöscht.
Ja, für einen Cronjob braucht es einen weiteren Platz.
Aber schriebst du grad "Multipart-Request"? Dann kämest du ja doch wieder zur Rechnung 10 × 100MB = 1GB und damit auf Konfigurationswerte von 1GB statt 100MB. Bei solchen Größen würde ich nichr einen einzelnen Request mit vielen Teilen drin, sondern je Datei einen Request nehmen.
Dann benutze ich die Begrifflichkeit "Multipart-Request" vielleicht falsch. Ich dachte, immer wenn per http etwas hochgeladen wird, spricht man von einem "Multipart-Request".
Ich hatte ursprünglich mal vor, ein Formular zu bauen, mit dem der User PDFs auf den Server laden kann. Diese PDFs sollten dann nach einer serverseitigen Validierung direkt aus dem upload_tmp_dir per Mail versendet werden. Über die Dateigrössen hatte ich mir nie Gedanken gemacht, bis dann klar wurde, dass sie sich nicht so einfach per Mail verschicken lassen, weil sie so gross sind. Gut, dachte ich mir, dann werden sie halt nicht per Mail verschickt, sondern mit php per ftp auf eine andere Maschine geladen. Dass sich die Aufgabenstellung aufgrund der Dateigrösse verändert, hatte ich nicht gedacht. In Deinem letzten Posting habe ich zwei, sagen wir mal, Impulse gelesen:
- Die Uploads in einzelne Requests aufteilen
- Die Weiterverarbeitung der Files nach dem Upload einen Hintergrundprozess machen lassen
Damit wird die Aufgabe komplexer aber beide klingen vernünftig. Nur warum?
-
Die Zeit, die der User warten muss, bis all seine Daten übertragen wurden unterscheidet sich ja nicht wesentlich dadurch, wenn für jedes input[type=file] ein eigener Request gestartet wird statt in eine Request alle Files auf einmal zu übertragen.
-
Wenn die Files nach dem Upload und einer Validierung mit php per ftp verschoben werden, ist es zunächst mal so, dass der User abwarten muss, bis php damit fertig ist. Deshalb hatte ich danach gesucht, ob sich das umgehen lässt und ignore_user_abort(true) gefunden. Keine Ahnung, ob es damit geht, ob das irgendwelche Problem nach sich zieht.
Obwohl ich nicht genau sagen kann warum, zweifle ich langsam an der Aufgabe an sich und ich weiss nicht mal warum ;)
gruss, heinetz