Является ли ini set ('max execution time', 0) плохой идеей?

есть ли веская причина не устанавливать переменную конфигурации PHP max_execution_time к 0?

сотрудник недавно внес изменения в файл, который добавил:

ini_set('max_execution_time', 0);

значение по умолчанию было слишком низким для страницы, которая выполняла сложную обработку перед возвратом вывода пользователю.

в руководстве указано, что основной целью настройки является:

предотвратить плохо написанные сценарии от связывания сервер.

но также продолжает утверждать:

ваш веб-сервер может иметь другие конфигурации тайм-аута, которые также могут прерывать выполнение PHP. Apache имеет автоотключение директива и IIS имеет функцию таймаута CGI. Оба по умолчанию 300 секунд. Подробные сведения см. В документации по веб-серверу.

мы работаем под Apache, так что автоотключение параметр применяется. Есть ли причина не устанавливать max_execution_time к нулю в глобальном масштабе? Мне в основном любопытно, есть ли преимущества, которые я упускаю, когда не установка его на ноль.

2 52
php

2 ответа:

рискуя вас раздражать;

вы задаете неправильный вопрос. Вам не нужна причина, чтобы не отклоняться от значений по умолчанию, но наоборот. Вам нужна причина, чтобы сделать это. Тайм-ауты абсолютно необходимы при запуске веб-сервера, и отключить этот параметр без причины по своей сути противоречит хорошей практике, даже если он работает на веб-сервере, который имеет собственную директиву тайм-аута.

теперь, что касается реального ответа; вероятно, это в данном конкретном случае это не имеет никакого значения, но это плохая практика, чтобы идти путем установки отдельной системы. Что делать, если скрипт позже запускается на другом сервере с другим таймаутом? Если вы можете смело сказать, что этого никогда не произойдет, прекрасно, но хорошая практика в основном заключается в учете кажущихся маловероятными событий и не связывая излишне настройки и функциональность совершенно разных систем. Отказ от таких принципов несет в себе много бессмысленного несовместимости в мире программного обеспечения. Почти каждый раз они бывают непредвиденными.

Что делать, если веб-сервер позже настроен на запуск какой-либо другой среды выполнения, которая наследует только параметр тайм-аута от веб-сервера? Предположим, например, что вам позже понадобится 15-летняя программа CGI, написанная на C++ кем-то, кто переехал на другой континент, который понятия не имеет о каком-либо таймауте, кроме веб-сервера. это может привести к необходимости изменения таймаута и потому что PHP бессмысленно полагаться на тайм-аут веб-сервера вместо своего собственного, Что может вызвать проблемы для PHP-скрипта. Или наоборот, по какой-то причине вам нужен меньший тайм-аут веб-сервера, но PHP все равно должен иметь его выше.

это просто не очень хорошая идея, чтобы привязать функциональность PHP к веб-серверу, потому что веб-сервер и PHP отвечают за разные роли и должны быть сохранены как можно функциональнее отдельно. Когда стороне PHP требуется больше времени на обработку, она должен быть параметр в PHP просто потому, что он имеет отношение к PHP, а не обязательно ко всему остальному на веб-сервере.

короче говоря, это просто излишне смешивать вопрос, когда в этом нет необходимости.

и последнее, но не менее важное: "stillstanding" правильно; вы должны, по крайней мере, использовать set_time_limit() чем ini_set().

надеюсь, это не было слишком покровительственным и раздражающим. Как я уже сказал, Возможно, это нормально при ваших конкретных обстоятельствах, но это хорошая практика, чтобы не предположим, что ваши обстоятельства являются единственными истинными обстоятельствами. Вот и все. :)

60

причина в том, чтобы иметь какое-то значение, отличное от нуля. Общая практика, чтобы она была короткой глобально и долго для длинных рабочих сценариев, таких как Парсеры, искатели, дамперы, экспорт и импорт сценариев и т. д.

  1. вы можете остановить сервер, повредить работу других людей по памяти потребляя сценарий, даже не зная об этом.
  2. вы не будете видеть ошибок где-то, скажем, бесконечный цикл произошел, и его будет сложнее диагностировать.
  3. такой сайт может быть легко дозируется одним пользователем, при запросе страниц с длительным временем выполнения
15