views:

26

answers:

3

In implementing the backup script I described in this serverfault question, I ran into some timeout issues that have prompted optimizations to the code (namely, backing up one file per execution of the script and doing everything I can to minimize the number of file-hashes I am calculating over the very large data files).

So far, that seems to have solved the timeout issue, but given the size of the files, there is certainly room for the transfer to take longer than the standard 30s allotted before a script times out. If that happens, I assume the file will simply be cut off as partially transferred. Is there any way to protect against this?

Note that I am operating on a shared-hosting environment, so editing the php.ini file is not an option.

+1  A: 

If it's enabled, you can call set_time_limit(). Alternatively, if you run php from the command line (via cron or similar), max execution time does not apply.

banzaimonkey
I am running via cron, but I was still getting "Fatal Error: Maximum execution time of 30s exceeded..." messages before my recent optimizations.
JGB146
Hm... maybe your SAPI is CGI and not not CLI, because of the shared hosting environment. You can check with php_sapi_name(): http://us2.php.net/manual/en/function.php-sapi-name.php
banzaimonkey
A: 

Can you try running the ftp job via the shell? Might work on a shared host...

shell_exec('nohup ftp my-ftp-command 2> /dev/null');
Jhong
A: 

According to set_time_limit(), this should never be an issue because time spent executing activities outside the script are not included when calculating execution time of the script for timeout issues.

JGB146
I'm running a battery of tests, with some files > 500MB in size, so we should see whether or not this holds in my specific situation.
JGB146