Abbruch durch 'set_time_limit()'

[Tylor]

Hallo zusammen,

ich führe in meinem Lan auf einem Lamp-Server ein PHP-Script aus, dass zum http-Upload von Dateien genutzt wird. Ich überprüfe die Dateigröße des Uploads durch die globale Varible '$_FILES[dateiname][size]’ und gestatte hier z.B. 1 MB. In der php.ini ist 'upload_max_filesize = 2M’, also 2MB, das Limit.
Wird das scriptseitige Limit von 1 MB beim Upload überschritten, bleibt aber unter dem Serverlimit von 2 MB, greift die scriptseitige Begrenzung mit der Verwendung von '$_FILES[dateiname][size]’. Wenn der Upload das Serverlimit von 2 MB übersteigt, funktioniert die Überprüfung der Dateigröße mit '$_FILES[dateiname][size]’ nicht mehr und der Upload wird durch den Rückgabewert von copy() abgebrochen. Das wäre alles kein Problem, wenn bei einer riesigen Upload-Datei die Wartezeit auf den Abbruch nicht so lang wäre. Bei einem Upload-Versuch von 30 MB-Dateien kann es bei einem nicht ganz taufrischem Rechner schon mal 45 Sekunden dauern bis die Abruchmeldung der copy-Funktion ausgeführt wird.

Ich habe dann überlegt, die Ausführungszeit des Scriptes durch 'set_time_limit()’ zeitlich zu limitieren. Vergeblich. Sowohl die Einstellung in der php.ini des Apache zum Limitieren der Ausführungszeit als auch die Verwendung von 'set_time_limit()’ hatten keinen Effekt. Ich habe dann im Forums-Archiv erfahren, dass 'set_time_limit()’ nur die Ausführungszeit des Scriptes als solches betrifft. D.h., dass z.B. die Ausführungszeiten von Datenbankabfragen oder inkludierten Scripten nicht mitgezählt werden. Trifft das dann auch auf den ‚header-Verkehr’ zur Ermittlung der Dateigröße zu? Kann man da irgendetwas anstellen, das mein Script bei einer Riesendatei die Sache schneller beendet?

Danke

Tylor

[wahsaga]

hi,

Ich habe dann im Forums-Archiv erfahren, dass 'set_time_limit()’ nur die Ausführungszeit des Scriptes als solches betrifft. D.h., dass z.B. die Ausführungszeiten von Datenbankabfragen oder inkludierten Scripten nicht mitgezählt werden. Trifft das dann auch auf den ‚header-Verkehr’ zur Ermittlung der Dateigröße zu?

wenn du von den HTTP-headern sprichst, die beim upload einer datei vom client mitgeschickt werden - zu diesem zeitpunkt ist dein script noch gar nicht aktiv. also hast du auch keine möglichkeit, zu diesem zeitpunkt schon mit PHP einfluss zu nehmen.

Kann man da irgendetwas anstellen, das mein Script bei einer Riesendatei die Sache schneller beendet?

m.W. kannst du höchstens per maxlength-attribut im file-feld den client _bitten_, keine größeren dateien hochzuladen.
wenn er sich daran nicht halten will, gibt es aber m.W. wenig möglichkeiten, dein problem zu umgehen.

gruß,
wahsaga

[Tylor]

m.W. kannst du höchstens per maxlength-attribut im file-feld den client _bitten_, keine größeren dateien hochzuladen.
wenn er sich daran nicht halten will, gibt es aber m.W. wenig möglichkeiten, dein problem zu umgehen.

Schade eigentlich. Danke für die promte Antwort !

Gruß
Tylor

[Tom]

Hello,

ein Rechner, der 45 Sekunden benötigt, um ein File von 30MB innerhalb eines Filesystems zu kopieren, muss eigentlich noch mit Diskettenlaufwerken arbeiten. Anders ist das i.d.R. nicht vorstellbar.

Allerdings könnte Dir die max_input_time von PHP eventuell weiterhelfen.

Ein Copy von 30MB sollte aber selbst bei einem alten Rechner innerhalb von 7Sek. erledigt sein. Wenn es sich um ein Linux-OS oder ein neueres Windows handelt, wird bei einer Gesamtkopie des Files außerdem gar nicht mehr unbedingt physisch kopiert, sondern nur die Einsprungs-Node auf das andere Verezichnis "umgebucht". Das geht (to Plate) innerhalb von ca. 8 bis 30ms.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[wahsaga]

hi,

ein Rechner, der 45 Sekunden benötigt, um ein File von 30MB innerhalb eines Filesystems zu kopieren, muss eigentlich noch mit Diskettenlaufwerken arbeiten. Anders ist das i.d.R. nicht vorstellbar.

es ist ja kein simples kopieren, sondern ein upload über HTTP, wenn ich richtig verstanden habe.

also datei durch client einlesen -> daten im client in HTTP-stream "umwandeln", zuzügl. des kompletten dadurch entstehenden overheads -> diese daten per HTTP an den server übertragen -> dort HTTP-stream wieder "dekodieren" und datei ins temp-verzeichnis stellen -> datei von dort an ihren wirklichen bestimmungsort kopieren

gruß,
wahsaga

[Tom]

Hello,

also datei durch client einlesen -> daten im client in HTTP-stream "umwandeln", zuzügl. des kompletten dadurch entstehenden overheads -> diese daten per HTTP an den server übertragen -> dort HTTP-stream wieder "dekodieren" und datei ins temp-verzeichnis stellen -> datei von dort an ihren wirklichen bestimmungsort kopieren

Ja, für den ersten Teil gilt max_input_time und für das reine Kopieren dann erst max_execution_time, die man mit set_time_limit() einstellen kann.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Tylor]

Ja, für den ersten Teil gilt max_input_time und für das reine Kopieren dann erst max_execution_time, die man mit set_time_limit() einstellen kann.

Hallo Tom,

es handelt sich um einen http-Upload. Weder die Begrenzung von max_input_time noch max_execution_time haben hier einen Effekt.
Die Sache scheint nichts mit der Laufzeit des Scriptes noch mit der Zeit des Request-parsing zu tun zu haben. Wasaga did right.

Gruß

Tylor

[Tom]

Hello,

es handelt sich um einen http-Upload. Weder die Begrenzung von max_input_time noch max_execution_time haben hier einen Effekt.

Ein http-Upload unterliegt der max_input_time. http://de.php.net/manual/en/ref.info.php#ini.max-input-time

Jede Abweichung von dieser Regel muss auf einem Bug basieren.

Die Sache scheint nichts mit der Laufzeit des Scriptes noch mit der Zeit des Request-parsing zu tun zu haben.

Scheint aber nur so. Vermutlich sind Deine Testbedingungen "Schrott" ;-)

Wasaga did right.

Was heißt das?

Harzliche Grüße aus http://www.annerschbarrich.de

Tom