| Both sides previous revisionPrevious revision | Last revisionBoth sides next revision |
| rfc:max_execution_wall_time [2020/12/21 19:10] – kocsismate | rfc:max_execution_wall_time [2020/12/21 19:32] – kocsismate |
|---|
| ===== Introduction ===== | ===== Introduction ===== |
| |
| On most platforms, PHP currently measures the request timeout based on CPU time, rather than wall-clock time, so neither ''sleep()'', nor network or system calls count towards the limit of the ''max_execution_time'' ini setting. This behavior is not only surprising, but it can have serious consequences for distributed systems with high traffic, where finishing a request in a timely manner is essential for avoiding cascading failures. | On most platforms, PHP currently measures the request timeout based on CPU time, rather than wall-clock time, so neither ''sleep()'', nor network or system calls count towards the limit of the ''max_execution_time'' ini setting. This behavior is not only surprising, but it can have serious consequences for high traffic application, where terminating requests which take too long time to process is essential for avoiding cascading failures. |
| |
| 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 timeout, 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. |
| |
| Let's consider the following piece of code to better illustrate the problem: | Let's consider the following piece of code to better illustrate the problem: |
| </PHP> | </PHP> |
| |
| Even though ''max_execution_time'' as well as ''CURLOPT_TIMEOUT'' are correctly set, this script can possibly run for ~100 seconds, given the cURL requests always time out. We can also run into the same problem while communicating through sockets, and not even setting the ''default_socket_timeout'' ini setting to a low value can help if there is a large number of requests. | Even though ''max_execution_time'' as well as ''CURLOPT_TIMEOUT'' are correctly set, this script can possibly run for ~100 seconds, given the cURL requests always time out. We can also run into the same problem while communicating through sockets, and not even setting the ''default_socket_timeout'' ini setting to a low value can help. |
| |
| 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. | 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. |