Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112523
MIME-Version: 1.0
References: <CAH5C8xW981Fn91HsHmZfbLseXwSyOtM1X5u1zsAL4ofXhka=nw@mail.gmail.com>
 <CAEPJdumFUe53ccUwCib_xJFuMQAu1sYXg_3Me4umnSrxbPUS3w@mail.gmail.com>
In-Reply-To: <CAEPJdumFUe53ccUwCib_xJFuMQAu1sYXg_3Me4umnSrxbPUS3w@mail.gmail.com>
Date: Wed, 16 Dec 2020 00:12:50 +0100
Message-ID: <CAH5C8xUAg3V8ELDJgDbj7qKhiNo3E3MfB4JnyWJxMe=AmBrbsw@mail.gmail.com>
To: Benjamin Eberlei <kontakt@beberlei.de>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000006ff36705b688e6c5"
Subject: Re: [PHP-DEV] [RFC] [Discussion] Measuring maximum execution time
 based on wall-time
From: kocsismate90@gmail.com (=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?=)

--0000000000006ff36705b688e6c5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Rowan and Benjamin,

we talked about this before and I think it's a good addition. Two
> suggestions to improve the RFC:
>

Thanks for the ideas, I'll incorporate more details about the interaction
of these settings. And I've just collected a few examples when my
proposal would be useful:
https://gist.github.com/kocsismate/dbcc4ba81b27cfb2e25b949723bb7c79 . Their
intention is to illustrate that no matter
how tight the individual timeout settings are, if the number of external
calls is high enough during the same request, nothing (*) can prevent the
response time
to skyrocket until all the workers become busy, causing outage because the
web server can't serve any new connections.

*except for some more complex, or non-clean mechanisms, which are outlined
in the RFC,

I'm struggling to picture when I'd want a hard wall-time limit, rather than=
:
> - checking the script's duration at key points where I know it can
> gracefully exit, ensure a consistent state, and return an appropriate
> message to the caller
> - enforcing a network timeout on the calling end so that I don't need to
> rely on all services cooperatively exiting in good time


In my opinion, the main problem with the first suggestion is that in
most cases, non-trivial production code can barely do anything like
"checking the script's duration
at key points". If there are enough levels of abstraction, the outermost
layers (e.g. controllers) can't do any checks, they simply have not enough
control.
On the other hand, having assumptions about the request duration in any
inner layers (e.g. model if we take MVC as an example) is a bad idea
according to my
experience. I admit though that there are some cases when it is possible to
add the checks in question, but I believe that would result in a very noisy
code,
while a simple ini config would do a much better service.

Do the above examples and this reasoning make sense to you? Also, I'll
improve the wording I used when describing the consequences.

Regards,
M=C3=A1t=C3=A9

--0000000000006ff36705b688e6c5--