Есть ли веская причина не устанавливать переменную конфигурации PHP max_execution_time в 0?
Сотрудник недавно проверил изменения в файле, который добавил:
ini_set('max_execution_time', 0);
Значение по умолчанию было слишком низким для страницы, которая выполняла некоторую сложную обработку перед возвратом вывода пользователю.
В руководстве указано, что основной целью настройки является:
предотвратить плохо написанные скрипты от привязки сервера.
Но также говорится:
Ваш веб-сервер может иметь другие конфигурации тайм-аутов, которые также могут прерывать выполнение PHP. У Apache есть директива Timeout, а IIS – функция тайм-аута CGI. Оба по умолчанию – 300 секунд. Подробную информацию см. В документации к веб-серверу.
Мы работаем под Apache, поэтому применяется параметр Timeout . Есть ли причина не устанавливать max_execution_time равным нулю во всем мире? Мне в основном любопытно, есть ли преимущества, которые я пропускаю, когда не устанавливаю его на ноль.
Рискуя вас раздражать;
Вы задаете неправильный вопрос. Вам не нужна причина, чтобы не отклоняться от значений по умолчанию, но наоборот. Вам нужно повод для этого. Тайм-ауты абсолютно необходимы при запуске веб-сервера и отключении этого параметра без причины, по сути, противоречат хорошей практике, даже если он работает на веб-сервере, который имеет собственную директиву тайм-аута.
Теперь, что касается реального ответа; вероятно, это не имеет никакого значения в данном конкретном случае, но плохой практикой является настройка отдельной системы. Что делать, если сценарий позже запускается на другом сервере с другим таймаутом? Если вы можете с уверенностью сказать, что этого никогда не будет, хорошо, но хорошая практика во многом связана с учетом кажущихся маловероятными событий и не лишним образом связывать настройки и функциональность совершенно разных систем. Увольнение таких принципов несет ответственность за множество бессмысленных несовместимостей в мире программного обеспечения. Почти каждый раз они непредвиденны.
Что делать, если веб-сервер позже настроен на запуск другой среды выполнения, которая только наследует параметр таймаута с веб-сервера? Скажем, например, что вам понадобится 15-летняя программа CGI, написанная на C ++ кем-то, кто переехал на другой континент, который не имеет ни малейшего представления о тайм-ауте, кроме веб-сервера. Это может привести к тому, что тайм-аут необходимо будет изменить и потому, что PHP бесцельно полагается на тайм-аут веб-сервера, а не на свой собственный, что может вызвать проблемы для PHP-скрипта. Или наоборот, вам нужно меньше тайм-аута веб-сервера по какой-то причине, но PHP все равно должен иметь его выше.
Просто не стоит связывать функции PHP с веб-сервером, потому что веб-сервер и PHP отвечают за разные роли и должны быть максимально функциональными. Когда стороне PHP требуется больше времени обработки, она должна быть параметром в PHP просто потому, что она имеет отношение к PHP, а не обязательно все остальное на веб-сервере.
Короче говоря, это просто излишнее объединение вопроса, когда нет необходимости.
И последнее, но не менее важное: «по-прежнему» верно; вы должны хотя бы использовать set_time_limit() чем ini_set() .
Надеюсь, это не слишком покровительственно и раздражало. Как я уже сказал, возможно, это хорошо в ваших конкретных обстоятельствах, но это хорошая практика, чтобы не считать ваши обстоятельства единственными истинными обстоятельствами. Это все. 🙂
Причина состоит в том, чтобы иметь какое-то значение, отличное от нуля. Общая практика заключается в том, чтобы сделать его коротким в глобальном масштабе и долго для длинных рабочих скриптов, таких как парсеры, сканеры, самосвалы, экспорт и импорт скриптов и т. Д.