6

The phrase "maximum execution time" is ambiguous: it could mean (a) the elapsed time since the script started, or (b) the total cputime taken by the script (including or excluding the cputime taken by operating system calls).

The very interesting post by kuba here Real max_execution_time for PHP on linux , finds that this depends upon whether PHP is running on Unix or Windows. In essence he finds that on Unix it is (b) and on Windows or Cygwin it is (a).

But, my server is Linux 2.6.32-358.18.1.el6.x86_64 #1 SMP x86_64 x86_64 x86_64 GNU/Linux, and I have a cron job that gets zapped after exactly 30 seconds elapsed time, despite its cpu time being less than 16 seconds:

[Tuesday, 10-Dec-2013 10:22:33 GMT] Begin, cputime=0 secs.
[Tuesday, 10-Dec-2013 10:22:58 GMT] starting zip_close, cputime=10.12946 secs.
[10-Dec-2013 10:23:03 UTC] PHP Fatal error:  Maximum execution time of 30 seconds exceeded in xxx.php on line 149

This contradicts kuba's finding. Mine is PHP 5.3.26 and IU'm measuring cpu time with:

function cputime() {
    $data = getrusage();
    return $data['ru_utime.tv_sec'] + $data['ru_utime.tv_usec'] / 1000000;

Can anyone clarify further?

Community
  • 1
  • 1
user3000292
  • 61
  • 2

3 Answers3

6

This depends entirely on your script. getrusage is not a reliable way to measure it. You're confused between 3 measurement methods, not 2:

  1. The absolute time since the startup of the script
  2. The runtime of the script, so 1. minus system calls
  3. Actual time the CPU is busy, so 2. minus other idle times because of wait states and the like

getrusage measures 3, and is not what is documented. As such you're seeing the conflicting results - apparently your script has 14 seconds of general wait states and other inactive periods, without actually yielding completely like you would with system or streaming operations.

As the PHP docs state Windows uses method 1, and *nix systems use method 2. Nobody uses 3 because it doesn't really make sense as a timeout - it would mean timeouts become extremely aggressively tighter when system load is high and wait states rise.

Niels Keurentjes
  • 41,402
  • 9
  • 98
  • 136
  • 1
    "This depend entirely on your script" - No, it depends entirely upon the code of PHP and the operating system. "You're confused" - No I'm not, I've identified a case where the behaviour is clearly not what the code found by kuba suggests, and I'm asking why. – user3000292 Dec 10 '13 at 12:50
  • 1
    Yes it depends entirely on your script - `getrusage` will vary incredibly depending on what you're actually doing in the script. You didn't identify an edge case, you're just measuring it wrong. Kuba says the script should run for "30 seconds plus any non-PHP time". Your log says your script ran from 10:22:33 to 10:23:03, exactly 30 seconds. So assuming you didn't do any `system` or streaming calls, his statement is 100% correct. – Niels Keurentjes Dec 10 '13 at 12:57
0

have a look at the documentation:

http://www.php.net/manual/en/info.configuration.php#ini.max-execution-time

how the programmers decided to implement the requirement it's obviously another story:) that's one of that cases in which the underlying OS matters a lot. The available APIs about cpu time on the particular OS will clearly shed some light on the problem.

this high-level requirement (the script running time) it's ambiguous and can be interpreted by the OS in many different ways. The proof is the different timings you get.

so there are many "right answers", exactly one per OS...

Gianluca Ghettini
  • 11,129
  • 19
  • 93
  • 159
0

AFAIK it is dependant on the OS. Depending on the OS, the time taken to execute a shell exec or query for example will (eg windows) or wont (eg linux) be included in the take for max_execution_time.

nl-x
  • 11,762
  • 7
  • 33
  • 61