On most platforms, PHP's max_execution_time measures CPU time, not real time, so time spent in sleep(), network calls or other system calls doesn't count. That means a script can run far longer than the limit you set. This RFC from Máté Kocsis proposed a new setting based on wall-clock time, the real time that passes while the script runs.

The problem

The RFC gives this example:

ini_set("max_execution_time", 10);

$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, "http://example.com/index.php");
curl_setopt($ch, CURLOPT_TIMEOUT, 1);

for ($i = 0; $i < 100; $i++) {
    curl_exec($ch);
}

Both limits are set, but if every request times out, this can run for about 100 seconds, because waiting on the network doesn't count toward the 10 second limit.

For high-traffic sites, that's a real risk, since slow requests pile up and can take other services down with them. php-fpm has request_terminate_timeout, but it's set per pool rather than per script. When it kills a request, shutdown functions don't run either, which breaks extensions that do monitoring.

What the RFC adds

A new ini setting, max_execution_wall_time, measured in seconds:

  • If a script runs longer than that, PHP stops it with a fatal error, the same way max_execution_time does.
  • The default is 0, which means no limit.
  • PHP checks after each call finishes, so a single slow call can still run past the limit before the error fires.
  • On Windows, IBM PASE and Cygwin, max_execution_time already uses wall-clock time, so there the two settings would share one timer.
  • A matching set_time_limit() style function is left out.

The RFC rejected changing max_execution_time itself, since that would break too much code. It also says a CPU time limit is still useful, for example to catch infinite loops.

What it means for existing code

Nothing breaks, because the new setting is off by default.

Where it stands

The author withdrew the RFC. It's dated December 12, 2020, targeted PHP 8.1, and never reached a vote.