65

Is there a good reason not to set the PHP configuration variable max_execution_time to 0?

A coworker recently checked in a change to a file that added:

ini_set('max_execution_time', 0);

The default value had been too low for a page that did some complex processing before returning the output to the user.

The manual states that the main purpose of the setting is to:

prevent poorly written scripts from tying up the server.

But also goes on to state:

Your web server can have other timeout configurations that may also interrupt PHP execution. Apache has a Timeout directive and IIS has a CGI timeout function. Both default to 300 seconds. See your web server documentation for specific details.

We're running under Apache, so that Timeout setting applies. Is there any reason not to set max_execution_time to zero globally? I'm mainly curious as to whether there are benefits I'm overlooking when not setting it to zero.

benizi
  • 4,046
  • 5
  • 28
  • 25
  • 3
    in php 7, it's ini_set('max_execution_time', '0'); (0 is a string, otherwise you get a TypeError). And yes, that's a good idea in dev if you need to execute heavy computations scripts. – ling Feb 11 '16 at 23:11

2 Answers2

69

At the risk of irritating you;

You're asking the wrong question. You don't need a reason NOT to deviate from the defaults, but the other way around. You need a reason to do so. Timeouts are absolutely essential when running a web server and to disable that setting without a reason is inherently contrary to good practice, even if it's running on a web server that happens to have a timeout directive of its own.

Now, as for the real answer; probably it doesn't matter at all in this particular case, but it's bad practice to go by the setting of a separate system. What if the script is later run on a different server with a different timeout? If you can safely say that it will never happen, fine, but good practice is largely about accounting for seemingly unlikely events and not unnecessarily tying together the settings and functionality of completely different systems. The dismissal of such principles is responsible for a lot of pointless incompatibilities in the software world. Almost every time, they are unforeseen.

What if the web server later is set to run some other runtime environment which only inherits the timeout setting from the web server? Let's say for instance that you later need a 15-year-old CGI program written in C++ by someone who moved to a different continent, that has no idea of any timeout except the web server's. That might result in the timeout needing to be changed and because PHP is pointlessly relying on the web server's timeout instead of its own, that may cause problems for the PHP script. Or the other way around, that you need a lesser web server timeout for some reason, but PHP still needs to have it higher.

It's just not a good idea to tie the PHP functionality to the web server because the web server and PHP are responsible for different roles and should be kept as functionally separate as possible. When the PHP side needs more processing time, it should be a setting in PHP simply because it's relevant to PHP, not necessarily everything else on the web server.

In short, it's just unnecessarily conflating the matter when there is no need to.

Last but not least, 'stillstanding' is right; you should at least rather use set_time_limit() than ini_set().

Hope this wasn't too patronizing and irritating. Like I said, probably it's fine under your specific circumstances, but it's good practice to not assume your circumstances to be the One True Circumstance. That's all. :)

Teekin
  • 12,581
  • 15
  • 55
  • 67
  • I'm mainly trying to understand the rationale for the default in the first place. Just because it's a default doesn't make it good. Having a default `max_execution_time` setting at all still strikes me the same as having an "infinite loop detector". And the PHP implementation (defaulting to 0 under 'cli', 30 otherwise) seems to contradict your "unnecessarily tying together the settings and functionality of completely different systems" argument. Nonetheless, you've provided a well-written, principled answer with good examples. Thanks. – benizi Nov 29 '10 at 19:12
  • Well, in a command-line environment you never get rid of having to deal with the environment (hence the importance of POSIX-compliance) so it's not exactly comparable. But even on top of that, CLI PHP is relatively new; PHP wasn't intended as a CLI environment until version... 4.5 or even 5, I think. – Teekin Nov 29 '10 at 21:27
  • 3
    Who is 'stillstanding' and where can I find him? – Buttle Butkus Apr 17 '14 at 20:09
  • 3
    Curious, what's the difference between `ini_set('max_execution_time', ...)` and `set_time_limit(...)`? I thought they were identical. – Samuel Katz Dec 10 '15 at 17:09
  • 3
    @SalmanAbbas See http://stackoverflow.com/questions/8914257/difference-between-set-time-limit-and-ini-setmax-execution-time - not quite identical but near enough it would seem. Perhaps it was different back in 2010? – Eborbob Aug 24 '16 at 13:21
17

Reason is to have some value other than zero. General practice to have it short globally and long for long working scripts like parsers, crawlers, dumpers, exporting & importing scripts etc.

  1. You can halt server, corrupt work of other people by memory consuming script without even knowing it.
  2. You will not be seeing mistakes where something, let's say, infinite loop happened, and it will be harder to diagnose.
  3. Such site may be easily DoSed by single user, when requesting pages with long execution time
HelloDolly1
  • 171
  • 1
  • 2