Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112488
To: internals@lists.php.net
References: <CAH5C8xVuRnsfO+_L+_zFD2uP9dJ3UNBNndCMcQPTnPmybtB8-g@mail.gmail.com>
Message-ID: <7a20cd8a-f38a-cbfe-1ae7-0b69351bc37e@gmail.com>
Date: Fri, 11 Dec 2020 10:22:42 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.5.1
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: 8bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] [RFC] Measuring maximum execution time based on
 wall-time
From: rowan.collins@gmail.com (Rowan Tommins)

On 11/12/2020 09:59, Máté Kocsis wrote:
> 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 most users, the max execution time is not really a precise metric, 
but a backstop to prevent against a process running forever - for 
instance, it will trap an accidental infinite loop (accidental infinite 
recursion, meanwhile, is often caught by the memory limit in my experience).

For that use case, it can actually be desirable to exclude things like 
database and network calls (i.e. to use CPU time rather than wall time) 
because they will vary for completely different reasons and on different 
scales.

For instance, if an SQL query takes 30 seconds, you might want to log 
that and work on optimising it, but your application is still 
functional. However, if a normal web page uses 30 seconds of CPU time in 
the main thread, something has probably gone seriously wrong, and you 
probably want to kill the process to stop it using all the server's 
resources.

I think your proposal to allow both limits to be set independently is 
sensible, and imagine that most users will want a much higher clock-time 
limit than the CPU-time limit.

Regards,

-- 
Rowan Tommins (né Collins)
[IMSoP]