Является ли ini_set ('max_execution_time', 0) плохой идеей?

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

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

 ini_set('max_execution_time', 0); 

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

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

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

Но также говорится:

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

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

Solutions Collecting From Web of "Является ли ini_set ('max_execution_time', 0) плохой идеей?"

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

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

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

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

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

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

И последнее, но не менее важное: «по-прежнему» верно; вы должны хотя бы использовать set_time_limit() чем ini_set() .

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

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

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