[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: 504 при полном завершении работы скрипта
соучастник
Привет всем, есть вопрос- скрипт отрабатывает свой сценарий полностью, подтверждением тому является сохраненная за счет ob_get_contents(); в файл инфа, но на экран выводиться 504 ошибка скрипт размещен на хостинге и вот так работает на локальном денвере все работает нормально в чем может быть проблема?
соучастник
сервак nginx
Guest
понял, получается что нджинкс с апачем не согласовывается и законно отдает 504 ошибку при исчерпании своего лимита времени, а апач из скрипта получает задачу работать без оставноки
Guest
новый вопрос что делать если в нджинксе нельзя ничего менять
Nikitian
Видимо php не успевает ответить в лимит ожидания ответа от бэкенда у nginx. Увеличьте параметр proxy_read_timeout больше, чем максимальное время выполнения php.

Если ничего менять нельзя, то разбейте долгую задачу на этапы и по этапам, чтобы каждый этап укладывался в лимит.
Guest
Если ничего менять нельзя, то разбейте долгую задачу на этапы и по этапам, чтобы каждый этап укладывался в лимит.
т.е. получается несколько раз запускать скрипт?
Nikitian
Да. Пересмотрите структуру под существующие ограничения. Если скрипт предполагает работу с контролем через браузер, то можно обратить внимание на вариант последовательного запуска через javascript на управляющей странице, либо вручную. Либо скрипт подходя к известному лимиту времени исполнения будет прерываться и генерировать простейшую конструкцию на html или javascript для перезапуска самого себя.
Так же существует вариант запуска через cron, когда запускаемый скрипт будет сам разбираться где он окончил в предыдущий свой запуск и продолжать работу с места обрыва. Разумеется, необходимо предусмотреть вариант параллельного запуска, когда крон запускает скрипты, а его предыдущая версия ещё не отработала. Такой вариант надо предусмотреть и либо использовать во благо ради ускорения выполнения общей работы за счёт распараллеливания, либо пресекать.
Guest
Nikitian
спасибо все это понятно просто первый раз сталкиваюсь с такого рода проблемой обычно базу заливал без проблем, но видимо всегда есть куда расти) еще раз спасибо
Guest
Nikitian
такой вопрос если я в начале работы скрипта подключилс к бд то по истечение лимита его действия если апач все еще работает соединение с базой может отвалится? просто база отказывает а видимых причин нет
Nikitian
Апач работает с базой, а лимит у вас на nginx истекает. По окончании лимита апач может работать с базой, но если производятся какие-то долгие действия без участия базы, то уже мускуль может разорвать соединение по своему таймауту. Обычно, если это происходит, достаточно воспользоваться mysql_ping() или его более современными аналогами.

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

Вся проблема в идеологии php как генератора страниц. Это язык не рассчитывался для разработки долгоиграющих приложений. Именно поэтому и приходится делать все эти грабли, особенно дико это воспринимается, при переходе с программирования прикладных приложений. Тут всегда надо держать в памяти клиент-серверную модель взаимодействия.
killer8080
Цитата (Nikitian @ 11.02.2013 - 10:07)
Это язык не рассчитывался для разработки долгоиграющих приложений.

от чего же, если запускать в CLI никаких лимитов времени по умолчанию нет, можно и демон написать на PHP.
Nikitian
Цитата (killer8080 @ 11.02.2013 - 12:27)
Цитата (Nikitian @ 11.02.2013 - 10:07)
Это язык не рассчитывался для разработки долгоиграющих приложений.

от чего же, если запускать в CLI никаких лимитов времени по умолчанию нет, можно и демон написать на PHP.

Это уже костыль. Да и всё-равно, пых течёт так, что никогда не рискну на нём писать что-то, работающее продолжительное время. Для всего свои инструменты.
vasa_c
можно какое-нибудь говно периодически отдавать.
например, header('HTTP/1.1 Continue'), может поможет

_____________
Блог ГО | Таблица символов Юникода | Графомания
killer8080
Цитата (Nikitian @ 11.02.2013 - 10:30)
Это уже костыль. Да и всё-равно, пых течёт так, что никогда не рискну на нём писать что-то, работающее продолжительное время. Для всего свои инструменты.

делал как то демона, правда однопроцессового, ничего там не течет, если все по уму делать. Может с какими то отдельными расширениями проблемы, не знаю, но сам пых стабилен, утечек нет.
Естественно, что тяжелые задачи не должны запускаться в веб контексте, и было бы глупо обвинять в этом php.
Nikitian
В том-то и дело, что сам пых практически ничего не умеет. Шаг от алгоритмики в сторону взаимодействия с каким-то софтом, железом или просто выход за пределы возможностей вычисления пыха и добро пожаловать в широкий мир расширений, слепленных на коленке, за стабильность которых никто не поручится.
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2024 Invision Power Services, Inc.