PHP max_execution_time 的确切含义答案

【问题标题】：Exact meaning of PHP max_execution_timePHP max_execution_time 的确切含义
【发布时间】：2013-12-10 11:27:40
【问题描述】：

短语“最大执行时间”不明确：它可能表示 (a) 自脚本启动以来经过的时间，或 (b) 脚本占用的总 cputime（包括或不包括操作系统调用占用的 cputime） .

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，IU 正在测量 CPU 时间：

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

谁能进一步澄清？

【问题讨论】：

标签： php unix time max execution

【解决方案1】：

这完全取决于您的脚本。 getrusage 不是衡量它的可靠方法。您对 3 种测量方法感到困惑，而不是 2 种：

脚本启动后的绝对时间
脚本的运行时，所以 1. 减去系统调用
CPU 忙碌的实际时间，因此 2. 减去由于等待状态等导致的其他空闲时间

getrusage 测量 3，不是记录的内容。因此，您会看到相互矛盾的结果 - 显然，您的脚本有 14 秒的一般等待状态和其他非活动期，没有实际上完全像 system 或流式操作那样产生。

正如 PHP 文档所述，Windows 使用方法 1，而 *nix 系统使用方法 2。没有人使用 3，因为它作为超时没有真正意义 - 这意味着当系统负载高时超时变得非常严格，并且等待状态上升。

【讨论】：

"这完全取决于你的脚本" - 不，它完全取决于 PHP 的代码和操作系统。 “你很困惑” - 不，我没有，我发现这种行为显然不是 kuba 发现的代码所暗示的，我在问为什么。
是的，这完全取决于您的脚本 - getrusage 会因您在脚本中实际执行的操作而异。您没有确定边缘情况，只是测量错误。 Kuba 说脚本应该运行“30 秒加上任何非 PHP 时间”。您的日志显示您的脚本从 10:22:33 运行到 10:23:03，正好是 30 秒。因此，假设您没有进行任何 system 或流式呼叫，他的说法是 100% 正确的。

【解决方案2】：

AFAIK 它依赖于操作系统。根据操作系统，执行 shell exec 或查询所花费的时间将（例如 windows）或不会（例如 linux）包含在 max_execution_time 的时间中。

【讨论】：

但我的意思是我在 Linux 下，它似乎使用的是纯粹的经过时间测量。

【解决方案3】：

查看文档：

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

程序员如何决定实现需求显然是另一回事：) 这是底层操作系统非常重要的情况之一。特定操作系统上有关 cpu 时间的可用 API 将清楚地阐明该问题。

这个高级要求（脚本运行时间）是模棱两可的，并且可以由操作系统以多种不同方式解释。证据就是你得到的不同时间。

所以有很多“正确答案”，每个操作系统只有一个...

【讨论】：