PHP max_execution_time的确切含义是什么？

Question

“最大执行时间”这个短语有歧义：它可能意味着(a)脚本启动后经过的时间，或者(b)脚本所需的总CPU时间（包括或不包括操作系统调用所需的CPU时间）。

在这里kuba的非常有趣的帖子Real max_execution_time for PHP on linux发现这取决于PHP是否在Unix或Windows上运行。他实质上发现在Unix上是(b)，而在Windows或Cygwin上是(a)。

但是，我的服务器是Linux 2.6.32-358.18.1.el6.x86_64 #1 SMP x86_64 x86_64 x86_64 GNU/Linux，并且我有一个cron作业，在经过30秒的时间后被终止，尽管它的CPU时间少于16秒：

[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

这与kuba的发现相矛盾。我的是PHP 5.3.26，我使用以下方法来测量CPU时间：

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

有人能进一步解释吗？

- user3000292

Answer 1

这完全取决于你的脚本。使用getrusage并不是一种可靠的测量方法。你混淆了3种测量方法，而不是2种：

1. 自脚本启动以来的绝对时间
2. 脚本的运行时间，即1.减去系统调用的时间
3. 实际CPU繁忙时间，即2.减去其他因等待状态等而产生的空闲时间

getrusage测量的是第3种情况，并不是文档中所述的内容。因此，你会看到矛盾的结果——显然你的脚本有14秒的普通等待状态和其他非活动周期，而没有像使用system或流操作一样完全放弃控制权。 正如PHP文档所述，Windows使用方法1，*nix系统使用方法2。没有人使用方法3，因为它作为超时时间并没有太多意义——当系统负载高且等待状态增加时，超时时间会变得极其紧张。

- Niels Keurentjes

---

这完全取决于你的脚本 - 不，它完全取决于PHP代码和操作系统。 "你混淆了" - 不，我没有，我已经确定了一个情况，其中行为显然不是kuba发现的代码所建议的，我想知道为什么。 - user3000292

是的，它完全取决于您的脚本 - getrusage 将根据您在脚本中实际执行的操作而有所不同。你没有确定一个边缘情况，你只是测量方式错误了。Kuba说脚本应该运行“30秒加上任何非 PHP 时间”。您的日志显示您的脚本从 10:22:33 运行到 10:23:03，正好是 30 秒。因此，假设您没有执行任何 system 或流调用，他的说法是 100% 正确的。 - Niels Keurentjes

Answer 2

请查看文档：

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

如何程序员决定实现需求显然是另一回事：） 这是其中一个情况，底层操作系统非常重要。特定操作系统上关于CPU时间的可用API将清楚地解决问题。

这个高级需求（脚本运行时间）是模糊的，可以被操作系统以许多不同的方式解释。证明是你得到的不同时间。

因此，有许多“正确答案”，每个操作系统都有一个...

- Gianluca Ghettini

Answer 3

据我所知，这取决于操作系统。根据操作系统的不同，执行shell exec或查询所需的时间（例如Windows）可能会被计入max_execution_time的时间限制，也可能不会（例如Linux）。

- nl-x

---

但我的观点是，我正在使用Linux，它似乎正在使用纯经过时间的度量。 - user3000292