是否有充分的理由不将PHP配置变量设置max_execution_time为0？
最近一位同事检查了一个文件的更改:
ini_set('max_execution_time', 0);
在将输出返回给用户之前,对于执行某些复杂处理的页面,默认值太低.
该手册指出该设置的主要目的是:
防止写得不好的脚本捆绑服务器.
但也接着说:
您的Web服务器可能具有其他可能会中断PHP执行的超时配置.Apache有一个Timeout指令,IIS有一个CGI超时功能.两者都默认为300秒.有关具体详细信息,请参阅Web服务器文档
我们在Apache下运行,因此适用Timeout设置.有没有理由不在max_execution_time全球范围内设置为零？我很好奇是否有什么好处我没有把它设置为零.
Tee*_*kin 64
冒着刺激你的风险;
你问的是错误的问题.您不需要有理由不偏离默认值,反之亦然.你需要一个理由这样做.运行Web服务器时超时是绝对必要的,并且在没有理由的情况下禁用该设置本质上与良好实践相反,即使它在具有自己的超时指令的Web服务器上运行.
现在,至于真正的答案; 可能在这种特殊情况下根本不重要,但是通过设置一个单独的系统是不好的做法.如果稍后在具有不同超时的其他服务器上运行该脚本会怎样？如果你可以肯定地说它永远不会发生,那很好,但是好的做法主要是考虑看似不太可能的事件,而不是不必要地将完全不同系统的设置和功能联系在一起.解散这些原则是造成软件世界中许多毫无意义的不兼容问题的原因.几乎每一次,他们都是无法预料的.
如果以后将Web服务器设置为运行仅从Web服务器继承超时设置的其他运行时环境,该怎么办？比如说,你后来需要一个15岁的CGI程序,这个程序是由一个移动到不同大陆的人用C++编写的,除了Web服务器之外不知道任何超时.这可能导致需要更改超时,并且因为PHP毫无意义地依赖于Web服务器的超时而不是自己的超时,这可能会导致PHP脚本出现问题.或者反过来说,由于某种原因,您需要较少的Web服务器超时,但PHP仍然需要更高.
将PHP功能与Web服务器联系起来并不是一个好主意,因为Web服务器和PHP负责不同的角色,并且应尽可能保持功能分离.当PHP方需要更多的处理时间时,它应该是PHP中的一个设置,因为它与PHP相关,而不一定是Web服务器上的其他所有内容.
简而言之,在没有必要时,它只是不必要地混淆了这个问题.
最后但同样重要的是,"仍然"是正确的; 你至少应该使用set_time_limit()比ini_set().
希望这不是太过光顾和刺激.就像我说的那样,在你的具体情况下可能没什么问题,但最好不要把你的情况假设成一个真实的环境.就这样.:)
小智 16
原因是有一些非零的价值.通常的做法是让它在全局范围内缩短,并且长时间使用解析器,爬虫,转储器,导出和导入脚本等长工作脚本.
| 归档时间： |
|
| 查看次数： |
157472 次 |
| 最近记录： |