| Both sides previous revisionPrevious revision | Next revisionBoth sides next revision |
| rfc:max_execution_wall_time [2020/12/13 00:24] – kocsismate | rfc:max_execution_wall_time [2020/12/21 18:48] – kocsismate |
|---|
| Even if each individual network/system calls have their own timeouts, execution time can still horribly go out of control when there are hundreds or even thousands of such calls during the same request. This risk also applies to CLI scripts which can possibly execute millions of database queries or API requests. | Even if each individual network/system calls have their own timeouts, execution time can still horribly go out of control when there are hundreds or even thousands of such calls during the same request. This risk also applies to CLI scripts which can possibly execute millions of database queries or API requests. |
| |
| To make things even worse, none of the most popular web servers offer a convenient solution. I.e. when using PHP-FPM as process manager, the ''request_terminate_timeout'' pool-level config option is available for stopping execution after a certain amount of time at latest. This can help, but it still falls short when there is a wide variety of acceptable timeout settings for the individual scripts. So in the end, one would have to maintain different pools for slow and fast scripts... Clearly, this can quickly become a burden. Not to mention the fact that ''RSHUTDOWN'' is not invoked in case of a PHP-FPM timeout, so any extensions that do monitoring are rendered useless. | To make things even worse, none of the most popular web servers offer a convenient solution. I.e. when using PHP-FPM as process manager, the ''request_terminate_timeout'' pool-level config option is available for stopping execution after a certain amount of time at latest. This can help, but it still falls short when there is a wide variety of acceptable timeout settings for the individual scripts. So in the end, one would have to maintain different pools for slow and fast scripts... Clearly, this can quickly become a burden. Not to mention the fact that neither shutdown handlers, nor the ''RSHUTDOWN'' internal function* is invoked in case of a PHP-FPM timeout, so any extensions that do monitoring are rendered useless. |
| | |
| | (*) ''RSHUTDOWN'' internal function: it is used by extensions to clean up their resources after each request. |
| |
| Another solution for the problem could be using something like: | Another solution for the problem could be using something like: |
| ===== Proposal ===== | ===== Proposal ===== |
| |
| This RFC proposes to add a ''max_execution_wall_time'' ini setting. If a script runs longer than the value of ''max_execution_wall_time'', measured in seconds according to wall-clock (or real) time, a fatal error is raised. By default, the value of the ini setting is ''0'', which means that the allowed script duration is unlimited. | This RFC proposes to add a ''max_execution_wall_time'' ini setting. If a script runs longer than the value of ''max_execution_wall_time'', measured in seconds according to wall-clock (or real) time, a fatal error is raised, similarly to what happens in case of "max_execution_time". By default, the value of the ini setting is ''0'', which means that the allowed script duration is unlimited. |
| |
| A limitation of the implementation is that the timeout takes into effect on a best-effort basis, meaning that the fatal error is triggered only after the call exceeding the time limit is finished. This is in line with the current timeout behavior, and the RFC considers this as an acceptable limitation. | A limitation of the implementation is that the timeout takes into effect on a best-effort basis, meaning that the fatal error is triggered only after the call exceeding the time limit is finished. This is in line with the current timeout behavior, and the RFC considers this as an acceptable limitation. |