Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112489
To: internals@lists.php.net
References: <CAH5C8xVuRnsfO+_L+_zFD2uP9dJ3UNBNndCMcQPTnPmybtB8-g@mail.gmail.com>
Message-ID: <ff7b350c-31fa-7ed5-b42f-110d1c1009b1@gmx.net>
Date: Fri, 11 Dec 2020 11:58:52 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: <CAH5C8xVuRnsfO+_L+_zFD2uP9dJ3UNBNndCMcQPTnPmybtB8-g@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Subject: Re: [PHP-DEV] [RFC] Measuring maximum execution time based on
 wall-time
From: a.leathley@gmx.net (Andreas Leathley)

On 11.12.20 10:59, M=C3=A1t=C3=A9 Kocsis wrote:
> That's why I'd like to add support for measuring the execution timeout
> based on the wall-time. There are a couple of ways to approach the probl=
em
> though:
> - by measuring wall-time on all platforms
> - by adding a new "max_execution_time_type" or so ini setting for
> optionally changing the meaning of max_execution_time (this is what HHVM=
 is
> doing)
> - by adding a new "max_execution_wall_time" ini setting for being able t=
o
> timeout based on both the real execution time and the CPU time.
>
> My POC implementation at https://github.com/php/php-src/pull/6504 curren=
tly
> uses the third solution, but I would be okay with the other possibilitie=
s
> as well (especially with the first one). I would also be very curious if
> anyone is aware of the reasons why the CPU time metric was chosen back
> then? In my opinion, wall-time is much more useful, but maybe I'm just
> missing some technical limitations (?).

For my applications the current behavior is the more important one, but
implementing both (and being able to set both limits independently)
would be an interesting improvement.

Next to having hard limits, having a way similar to FPMs
request_slowlog_timeout in PHP would be a useful addition in my opinion:
to detect slow requests/scripts and report them, as that can be an early
warning and something worthy to analyze. Basically, set a time limit for
either cpu or wall time, or both, and if that limit is reached call a
PHP callable to report it or handle it in some way (similar to how
pcntl_signal can act on signals in an async way). This would open up
more options, as the current max_execution_time or a new
max_execution_wall_time would be a last resort, but most of the time I
would rather know about a problem early on and log it.