php долгое выполнение скрипта
Проблемы «долгих» скриптов PHP
Внешний таймаут
В первую очередь нужно установить подходящее значение параметра max_execution_time в конфиге PHP.
Веб-сервер может также проксировать запросы на другой веб-сервер, который и запустит PHP скрипт (не редкий пример, nginx — фронтенд, apache — бэкэнд). В этом случае на проксирующем веб-сервере необходимо также настраивать таймаут проксирования. Для apache ProxyTimeout, для nginx proxy_read_timeout.
Прерывание пользователем
Если скрипт запускается в ответ на HTTP-запрос, то пользователь может остановить выполнение запроса в своем браузере, в этом случае прекратит свою работу и PHP скрипт. Если же требуется, чтобы скрипт продолжил свою работу даже после остановки запроса, установите в TRUE параметр ignore_user_abort в конфиге PHP.
Потеря открытых соединений
В таких случаях следует в первую очередь попробовать увеличить таймаут соединения. Например, для MySQL можно выполнить запрос (спасибо Snowly)
Параллельный запуск
В таких случаях можно использовать блокировку используемых ресурсов, но эта задача всегда решается индивидуально. Либо можно просто проверять, не запущена ли другая копия этого скрипта, и либо подождать завершения его работы, либо завершить текущий запуск. Для этого можно просматривать список запущенных процессов, либо использовать блокировку запуска самого скрипта, что то вроде:
Нагрузка на веб-сервер
В случаях, когда долгие скрипты запускаются через веб-сервер, соединение клиента с этим самым веб-сервером остается открытым до тех пор, пока не отработает скрипт. Это не есть хорошо, т.к. задача веб-сервера как можно быстрее обработать запрос и отдать результат. Если же соединение остается висеть, то один из воркеров (процессов) веб-сервера на долгое время будет занят. А если одновременно будет запущено достаточно много таких скриптов, то они могут занять все (ну или почти все) свободные воркеры (для apache см. MaxClients), и веб-сервер просто не сможет обрабатывать другие запросы.
Поэтому следует при обработке запроса пользователя, запускать скрипт в фоновом режиме через php-cli, чтобы не нагружать веб-сервер, а пользователю отвечать что его запрос обрабатывается. При необходимости можно периодически проверять состояние обработки при помощи AJAX запросов.
Вот, пожалуй, и все что я могу рассказать по этой теме. Надеюсь, для кого-то будет полезным.
Как увеличить время выполнения PHP-скрипта?
Если вы разрабатываете крупный проект, то на обработку некоторых данных ему может потребоваться большое количество времени. На разных хостингах стоят свои лимиты на такие действия, и если сюда вас привела необходимость увеличить это время – то я подробно расскажу, как это можно сделать.
Чтобы вы понимали, о чем идет речь, приведу небольшой пример. При выходе за выставленные рамки времени вы можете получить следующего рода ошибку:
Я расскажу о 4-х способах, как избавиться от нее.
Но стоить начать с того, что в каждом отдельном случае все перечисленные способы могут не работать, так как некоторые хостинг-провайдеры запрещают самим изменять этот параметр.
Увеличение времени выполнения PHP-скрипта через конфигурационный файл php.ini
В качестве первого способа для увеличения времени выполнения скрипта мы будем использовать файл конфигурации php.ini.
Для того чтобы точно узнать, где находится этот файл, прочитайте эту статью.
Открываете его удобным для вас способом и в самый низ вставляете:
Где «300» означает 300 секунд (меняете на свое). Этот файл, к сожалению, не на всех хостингах доступен пользователям для редактирования.
Увеличение времени выполнения PHP-скрипта через встроенную функцию «ini_set»
Второй способ основывается на использовании функции «ini_set». Ее вы вставляете непосредственно в сам файл скрипта, желательно в самый верх. Пример:
Здесь значение «300» вы также сменяете на нужное вам в секундах. Обратите внимание, что при использовании PHP в безопасном режиме эта функция будет недоступна.
Увеличение времени выполнения PHP-скрипта через встроенную функцию «set_time_limit»
Третий способ, наверное, один из самых популярных – использование функции «set_time_limit» для изменения времени выполнения скрипта. Также используется непосредственно в самом файле PHP. Пример:
Здесь «300» вы также изменяете на нужное вам значение. Вставлять код желательно в самом верху.
Последний вариант заключается в редактировании файла .htaccess, который находится в корне вашего сайта (если таковой отсутствует – создайте его).
В самый верх этого файла вставьте:
Значение «300» вы также меняете на свое.
Обратите внимание, что во всех случаях время выполнения скрипта указывается в секундах. Помимо этого, значение параметра во всех способах может принимать «0», что означает неограниченное время выполнения.
Как узнать, сколько времени отведено на выполнение PHP-скрипта?
После того, как одним из способов вы попытались изменить время выполнения скрипта, нужно узнать, действительно ли у вас это получилось.
Для этого создайте PHP-файл в корне вашего сайта, где выведите значение установленного времени:
Если время равняется тому, что вы указали – поздравляем вас, вы достигли желаемой цели. В противном же случае прочитайте статью еще раз, напишите в комментариях о вашей проблеме или направьте ее вашему хостинг-провайдеру.
Выполнение потенциально долгого php-скрипта, запущенного через cron
Скажу сразу, я не php-программист, но есть потребность в исполнении потенциально долгого скрипта (php) на виртуальном хостинге. Задача связана с обновлением [потенциально] большого числа записей в б/д. Для этого планирую создать cron-задание. В связи с этим такой вопрос: верно ли я понимаю, что скрипты, запускаемые с помощью штук типа cron не имеют ограничений по времени исполнения и памяти (за исключением относительно больших физических лимитов на память и процессорное время, установленных хостером для моего тарифа)? То есть не получится ли так, что скрипт проработает, например, минут 5, а потом тихо порушится, не закончив начатое? Существует ли гарантия, что скрипт отработает до конца и завершится корректно, пусть даже он будет шуршать медленно в фоновом режиме? И вообще, я иду в верном направлении в плане связки php-cron для озвученной выше задачи?
2 ответа 2
верно ли я понимаю, что скрипты, запускаемые с помощью штук типа cron не имеют ограничений по времени исполнения
Существует ли гарантия, что скрипт отработает до конца и завершится корректно
Гарантию дает только Господь бог. Это странный вопрос, который, разумеется, не может иметь положительного ответа.
Если речь только про вылет по времени выполнения, то да, гарантия есть. Но остальные причины вылета, от ошибок в скрипте до перезагрузки сервера никто не отменял.
Или, например, скрипт шуршит так долго, что следующий запуск по крону запускает вторую копию, которая ломает результаты работы первой.
я иду в верном направлении в плане связки php-cron для озвученной выше задачи
Ну, если нужно гарантировать непрерывную работу сервиса, то можно замутить самопального демона, типа шелл скрипта, который запускает команду в цикле. Но это зависит от задачи. Про которую, кстати сказать, в вопросе нет ни слова.
Прогресс выполнения тяжелой задачи в PHP
Случилось мне как-то иметь дело с тяжелым PHP-скриптом. Нужно было каким-то образом в браузере отображать прогресс выполнения задачи в то время, пока в достаточно длительном цикле на стороне PHP проводились расчёты. В таких случаях обычно прибегают к периодичному выводу строки вроде этой:
Этот вариант меня не устраивал по нескольким причинам, к тому же мне в принципе не нравится такой подход.
Итераций у меня было порядка 3000—5000. Я прикинул, что великоват трафик для такой несложной затеи. Кроме того, мне такой вариант казался очень некрасивым с технической точки зрения, а внешний вид страницы и вовсе получался уродлив: футер дойдет еще не скоро — после последнего уведомления о 100% выполнении задачи.
Увернуться от проблемы некрасивой страницы большого труда не составляло, но остальные минусы заставили меня обрадоваться и приступить к поискам более изящного решения.
Решение простое. Основанная страница — это пульт управления. С пульта можно запустить и остановить задачу. Эта страница инициирует XMLHttpRequest — стартует выполнение основной задачи. В процессе выполнения этой задачи (внутри основного цикла) скрипт отправляет клиенту один байт — символ пробела. На пульте в обработчике onreadystatechange мы, получая байт за байтом, сможем делать вывод о прогрессе выполнения задачи.
Схема такая. Скрипт операции:
Однако, итераций всего 50. Об этом мы знаем, потому что сами определили их количество в файле скрипта. А если не знаем или количество может меняться? При readyState == 2 мы можем получить информацию из заголовков. Давайте этим и воспользуемся для определения количества итераций:
А на пульте получим и запомним это значение:
Общая схема должна быть ясна. Поговорим теперь о подводных камнях.
Кроме того, то ли Nginx, то ли FastCGI, то ли сам Chrome считают, что инициировать прием-передачу тела ответа, которое содержит всего-навсего один байт — слишком расточительно. Поэтому нужно предварить всю операцию дополнительными байтами. Нужно договориться, скажем, что первые 20 пробелов вообще ничего не должны означать. На стороне PHP их нужно просто «выплюнуть» в вывод, а в обработчике onreadystatechange их нужно проигнорировать. На мой взгляд — раз уж вся конфигурационная составляющая передается в заголовках — то и это число игнорируемых пробелов тоже лучше передать в заголовке. Назовем это padding-ом.
На стороне клиента это тоже нужно учесть:
Откуда число 20? Если подскажете — буду весьма признателен. Я его установил экспериментальным путем.
С ее помощью можно обойти все уровни буферизации, вывести данные напрямую, после чего все буферы восстанавливаются.
Кстати, а почему именно пробел используется для уведомления о выполненной части задачи? Просто потому что почти любой формат представления данных в вебе такими пробелами не испортишь. Можно применить такой метод передачи уведомления о прогрессе операции, а после всего этого вывести отчет о результатах в JSON.
Если все привести в порядок, немного оптимизировать и дополнить код всеми возможностями, которые могут пригодиться, получится вот что:
Реализация пошаговой работы PHP-скрипта с помощью AJAX
Искал более-менее простое и универсальное средство для организации пошаговой работы скрипта, но так ничего и не нашел. Даже вопрос в QA задал, везде только общие фразы. Поэтому решил сам сделать такой инструмент.
Для чего это вообще нужно?
Бывает необходимо обработать скриптом какой-то очень уж большой файл, например, для импорта. Естественно, время работы скрипта увеличивается пропорционально размеру файла или количеству строк в нем.
Хотелось бы разбить обработку файла на несколько частей и запускать скрипт в работу уже по частям. 
Принцип реализации давно известен — обмен данными между сервером и клиентом:
Клиент запускает скрипт, тот выполняет несколько итераций и возвращает клиенту номер строки, на которой он остановился. После этого клиент делает новый запрос, в котором передает скрипту этот номер и скрипт продолжает работу дальше.
Собственно сам код
Для работы нам понадобятся:
Для оформления css взял несколько правил из Bootstrap.
Что в итоге
В поле url мы указываем, например, ссылку на файл, который нужно обработать, и запускаем скрипт. Появляется прогресс-бар, а мы сидим и ждем, когда он доползет до 100 %, чтобы увидеть результат работы.
Если у сообщества есть примеры реализации подобного функционала или вообще готовые решения для пошаговой работы со скриптами, буду благодарен ссылкам в комментариях.
UPD. Решение, адаптированное для MODX здесь.