Difference Between Set_Time_Limit() and Ini_Set('Max_Execution_Time', ...)

Difference between set_time_limit() and ini_set('max_execution_time', ...)

Looking at the current source:

/* {{{ proto bool set_time_limit(int seconds)
Sets the maximum time a script can run */
PHP_FUNCTION(set_time_limit)
{
zend_long new_timeout;
char *new_timeout_str;
int new_timeout_strlen;
zend_string *key;

if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "l", &new_timeout) == FAILURE) {
return;
}

new_timeout_strlen = zend_spprintf(&new_timeout_str, 0, ZEND_LONG_FMT, new_timeout);

key = zend_string_init("max_execution_time", sizeof("max_execution_time")-1, 0);
if (zend_alter_ini_entry_chars_ex(key, new_timeout_str, new_timeout_strlen, PHP_INI_USER, PHP_INI_STAGE_RUNTIME, 0 TSRMLS_CC) == SUCCESS) {
RETVAL_TRUE;
} else {
RETVAL_FALSE;
}
zend_string_release(key);
efree(new_timeout_str);
}
/* }}} */

set_time_limit() is indeed just a convenience wrapper around the according ini_set() call. It doesn't even seem to perform the advertised timer reset. (But I would guess the "timer" actually isn't a separate entity, but the ini value itself is used as such.)

Check if max_execution_time and memory_limit is set to desired values

Use

$max_time = ini_get("max_execution_time");
$memory_limit = ini_get('memory_limit');

to get max_execution_time & memory_limit. And using if check whether those values are set, if not apply yours.

Getting memory_limit:

$memory_limit = ini_get('memory_limit');
if (preg_match('/^(\d+)(.)$/', $memory_limit, $matches)) {
if ($matches[2] == 'M') {
$memory_limit = $matches[1] * 1024 * 1024; // nnnM -> nnn MB
} else if ($matches[2] == 'K') {
$memory_limit = $matches[1] * 1024; // nnnK -> nnn KB
}
}

It should be noted that ini_set('max_execution_time', 2700); and set_time_limit(2700); are not completely synonymous, because set_time_limit() "resets" the counter to 0, which ini_set() does not.

ini_set, set_time_limit, (max_execution_time) - not working

You can not change this setting with
ini_set() when running in safe mode.
The only workaround is to turn off
safe mode or by changing the time
limit in the php.ini.

-- PHP manual, Runtime Configuration, description of max_execution_time

Many hosts run in safe mode. The other server is most likely one of them.

Edit: The same restriction is in place on set_time_limit:

This function has no effect when PHP
is running in safe mode. There is no
workaround other than turning off safe
mode or changing the time limit in the
php.ini.

-- PHP manual, set_time_limit page

Is ini_set('max_execution_time', 0) a bad idea?

At the risk of irritating you;

You're asking the wrong question. You don't need a reason NOT to deviate from the defaults, but the other way around. You need a reason to do so. Timeouts are absolutely essential when running a web server and to disable that setting without a reason is inherently contrary to good practice, even if it's running on a web server that happens to have a timeout directive of its own.

Now, as for the real answer; probably it doesn't matter at all in this particular case, but it's bad practice to go by the setting of a separate system. What if the script is later run on a different server with a different timeout? If you can safely say that it will never happen, fine, but good practice is largely about accounting for seemingly unlikely events and not unnecessarily tying together the settings and functionality of completely different systems. The dismissal of such principles is responsible for a lot of pointless incompatibilities in the software world. Almost every time, they are unforeseen.

What if the web server later is set to run some other runtime environment which only inherits the timeout setting from the web server? Let's say for instance that you later need a 15-year-old CGI program written in C++ by someone who moved to a different continent, that has no idea of any timeout except the web server's. That might result in the timeout needing to be changed and because PHP is pointlessly relying on the web server's timeout instead of its own, that may cause problems for the PHP script. Or the other way around, that you need a lesser web server timeout for some reason, but PHP still needs to have it higher.

It's just not a good idea to tie the PHP functionality to the web server because the web server and PHP are responsible for different roles and should be kept as functionally separate as possible. When the PHP side needs more processing time, it should be a setting in PHP simply because it's relevant to PHP, not necessarily everything else on the web server.

In short, it's just unnecessarily conflating the matter when there is no need to.

Last but not least, 'stillstanding' is right; you should at least rather use set_time_limit() than ini_set().

Hope this wasn't too patronizing and irritating. Like I said, probably it's fine under your specific circumstances, but it's good practice to not assume your circumstances to be the One True Circumstance. That's all. :)

PHP ini_set max_execution_time and memory_limit not working

sleep() time does not count toward execution time because it is not executing any code while it is sleeping.

Note:

The set_time_limit() function and the configuration directive
max_execution_time only affect the execution time of the script
itself. Any time spent on activity that happens outside the execution
of the script such as system calls using system(), stream operations,
database queries, etc. is not included when determining the maximum
time that the script has been running. This is not true on Windows
where the measured time is real.

This includes sleep(), as is mentioned several times in the comments for both sleep() and for set_time_limit(), e.g.

riki151205-Jun-2007 05:29

Please note that, under Linux, sleeping
time is ignored, but under Windows, it counts as execution time.



Related Topics



Leave a reply



Submit