PHP: Кодирование продолжительных сценариев, когда серверы накладывают ограничение времени выполнения
Серверы FastCGI, например, накладывают ограничение времени выполнения на Сценарии PHP, которые не могут быть изменены с помощью set_time_limit() в PHP. IIS делает это также, я верю.
Я записал сценарий импорта для приложения PHP, которое работает хорошо под mod_php, но перестало работать под FastCGI (mod_fcgid), потому что сценарий уничтожается после определенного числа секунд. Я еще не знаю о способе обнаружить то, что Ваше ограничение по времени в этом случае и не решило, как я собираюсь обойти его. Выполнение его в маленьких блоках с перенаправлениями походит на один клудж, но как?
Какие методы Вы использовали бы при кодировании продолжительной задачи, такой как импорт или задача экспорта, где отдельный Сценарий PHP может быть завершен сервером после определенного числа секунд?
Предположите создание портативного сценария таким образом, Вы не обязательно знаете, будет ли PHP в конечном счете выполнен под mod_php, FastCGI или IIS или осуществляется ли максимальное время выполнения на уровне сервера. Это, вероятно, также исключает сценарии оболочки и т.д.
3 ответа
Используйте интерфейс командной строки PHP , на который не распространяются временные ограничения сценария, налагаемые веб-серверами. Если вам нужно автоматизировать выполнение вашего скрипта, вы можете запланировать его с помощью cron.
На самом деле вы говорите об очереди заданий. Это практика асинхронного запуска PHP-кода из внешнего запроса. В PHP есть два основных способа сделать это. Один из них - использовать программу под названием Gearman, другой - использовать очередь заданий сервера Zend, с которой я лично лучше знаком. У меня есть сообщение в блоге о том, как это сделать, под названием Do you Queue . Я обнаружил, что моя реализация чрезвычайно проста в использовании.
Вы также можете попробовать установить max_execution_time равным 0 перед выполнением вашей логики.
Выполнение этого небольшими порциями с переадресацией кажется одним кладжем, но как?
Именно так я справился с полным форумом резервное копирование базы данных (phpBB), когда встроенный механизм экспорта начал достигать предела max_execution_time.
Я делал это по одной таблице за раз, а для больших таблиц - кусками по 5000 строк. (Оказалось, что ограничивающим фактором для всего процесса было не время выполнения экспорта, а фактически размер файла, который phpmyadmin мог обработать при импорте.)
После каждого фрагмента экспорта я возвращал страницу с мета-тег обновления в заголовке, перенаправляющий сценарий обратно самому себе с указанием номера таблицы следующего блока и начальной строки в строке запроса.
<?php if(!$all_done){
$new_url=$_SERVER['PHP_SELF'].'?tablecount='.$count;
if(!$tabledone && ""!=$start_row && null!=$start_row){
$new_url.="&startrow=".$start_row;
} else {
$new_url.="&startrow=0";
}
echo('<meta http-equiv="refresh" content="0.5;url='.$new_url.'" />');
} ?>
Счетчики были так, чтобы я мог перебирать массив имен таблиц, который я получил с помощью SHOW TABLES.
До того, как у меня хватило ума отсеять гигантскую таблицу соответствия слов (которую phpBB может перестроить самостоятельно) из экспорта, этот сценарий резервного копирования занимал более получаса.