php - maximum - Es ini_set(''max_execution_time'', 0) una mala idea?
time out en php (2)
¿Hay alguna buena razón para no establecer la variable de configuración de PHP max_execution_time en 0?
Un compañero de trabajo revisó recientemente un cambio en un archivo que agregó:
ini_set(''max_execution_time'', 0);
El valor predeterminado había sido demasiado bajo para una página que realizó un procesamiento complejo antes de devolver la salida al usuario.
El manual establece que el objetivo principal de la configuración es:
evitar que los scripts mal escritos bloqueen el servidor.
Pero también dice:
Su servidor web puede tener otras configuraciones de tiempo de espera que también pueden interrumpir la ejecución de PHP. Apache tiene una directiva Timeout e IIS tiene una función de tiempo de espera CGI. Ambos predeterminados a 300 segundos. Consulte la documentación de su servidor web para obtener detalles específicos.
Nos estamos ejecutando bajo Apache, por lo que se aplica la configuración de tiempo de espera . ¿Hay alguna razón para no establecer max_execution_time a cero globalmente? Tengo curiosidad sobre si hay beneficios que estoy pasando por alto cuando no lo ajuste a cero.
A riesgo de irritarte;
Estás haciendo la pregunta incorrecta. No necesita una razón para NO desviarse de los valores predeterminados, sino al revés. Necesitas una razón para hacerlo. Los tiempos de espera son absolutamente esenciales cuando se ejecuta un servidor web y desactivar esa configuración sin una razón es inherentemente contrario a las buenas prácticas, incluso si se ejecuta en un servidor web que tiene una directiva de tiempo de espera propia.
Ahora, en cuanto a la respuesta real; probablemente no importe para nada en este caso particular, pero es una mala práctica usar un sistema diferente. ¿Qué sucede si el script se ejecuta posteriormente en un servidor diferente con un tiempo de espera diferente? Si puede decir con seguridad que nunca sucederá, está bien, pero las buenas prácticas consisten principalmente en dar cuenta de los eventos aparentemente improbables y no vincular innecesariamente la configuración y la funcionalidad de sistemas completamente diferentes. El rechazo de tales principios es responsable de muchas incompatibilidades inútiles en el mundo del software. Casi todas las veces, son imprevistos.
¿Qué sucede si el servidor web más tarde está configurado para ejecutar algún otro entorno de tiempo de ejecución que solo hereda la configuración de tiempo de espera del servidor web? Digamos, por ejemplo, que luego necesita un programa de CGI de 15 años de antigüedad escrito en C ++ por alguien que se mudó a otro continente, que no tiene idea de ningún tiempo de espera excepto el del servidor web. Eso podría ocasionar que se requiera cambiar el tiempo de espera y porque PHP se basa inútilmente en el tiempo de espera del servidor web en lugar del propio, lo que puede causar problemas para el script PHP. O al revés, que necesita un tiempo de espera del servidor web menor por alguna razón, pero PHP aún necesita tenerlo más alto.
No es una buena idea vincular la funcionalidad PHP con el servidor web porque el servidor web y PHP son responsables de diferentes roles y deben mantenerse lo más funcionalmente separados posible. Cuando el lado PHP necesita más tiempo de procesamiento, debe ser una configuración en PHP simplemente porque es relevante para PHP, no necesariamente todo lo demás en el servidor web.
En resumen, se trata de combinar innecesariamente el asunto cuando no es necesario.
Por último, pero no por ello menos importante, "inmovilizar" es lo correcto; al menos debería usar set_time_limit() que ini_set() .
Espero que esto no sea demasiado condescendiente e irritante. Como dije, probablemente esté bien en tus circunstancias específicas, pero es una buena práctica no asumir que tus circunstancias sean la Única Verdadera Circunstancia. Eso es todo. :)
La razón es tener algún valor distinto de cero. Práctica general para tenerlo corto globalmente y largo para secuencias de comandos de trabajo largas como analizadores sintácticos, rastreadores, volquetes, exportación e importación de secuencias de comandos, etc.
- Puede detener el trabajo corrupto del servidor de otras personas mediante una secuencia de comandos que consuma memoria sin siquiera saberlo.
- No verá errores en los que algo, digamos, bucle infinito sucedió, y será más difícil de diagnosticar.
- Tal sitio puede ser fácilmente DoSed por un solo usuario, al solicitar páginas con tiempo de ejecución largo