"504 Gateway Time-out" ошибка, поправьте меня если я не правильно что то скажу...
она ведь появляется если скрипт отрабатывает дольше указанного на серваке лимита. А вот если скрипт на кроне запустить, и он подвержен такой ошибке?
Если не прописать в самом файле скрипта отключение лимита, да
А можете подсказать как отключить ? Просто @set_time_limit(0); ?
Ну листинг от сервера и пхп зависит, но я бы рекомендовал не делать такое вообще. Надо писать скрипты так чтобы они не висели часами на выполнении. Если операция тяжёлая, правильнее будет разбить её на лёгкие части которые выполняются за 30-40 секунд, таймаут на серверах обычно 60 секунд. И настроить крон на запуск этого скрипта каждые пару минут. Чтобы не вешало систему. Это если у операции нагрузки и вычисления сложные.
А что такое операции? Пжл подробнее. Я знаю "скрипт" ) Скрипт запустился и висит в системе до завершения. Скрипт может отработать за 1 секунду, а может 1 месяц крутиться до завершения (хоть вечно, поднимая демоном при падении или итерационно - как загрузка прогрессбара с ооочень большим объёмом данных). Запустить скрипт на пыхе с середины нельзя. Внутри скрипта (файла) php к примеру функция. Вот функция загружает файл в 100мб (к примеру json) с удалённого серва, парсит его и создаёт в инфоблоке 100 000 записей. Или обновляет их. Скрипт работает без остановки 3-4 минуты. Как сделать "операции" по 30 секунд? Если будет 10 000 000 записей, да, будет работать час к примеру (чем более ресурсный серв тем меньше времени на выполнение), если скрипт упадёт или прервется, с перезапуском скрипта и механикой проверки уже созданных записей. В этом примере, как переписать скрипт на работу по "операциям за 30-40 секунд"? Пару часов работы скрипта это плохо? Почему? И что такое эти самые "операции"? У меня нейросеть на пыхе порой месяц работает без остановки, падений, прерываний...если пару часов плохо и нужно разбивать на какие то "операции" по 30 секунд...то как быть в этом случае? В общем, очень интересно, что это такое и с чем едят, просьба развернуть ответ или описать методу. Спасибо.
Да. Почитай как cron скрипты для битры писать. Иногда 504 признак косячного по архитектуре скрипта, который делает работу дольше, чем мог бы. Если скрипт проверил и все впорядке, да, сет лимит в ноль и ряд других констант и функций использовать.
у меня тоже есть сайты с такими операциями. я имею ввиду то что делает скрипт, чаще всего это однотипные действия с сущностями битрикс. если он обновляет или создаёт элементы из json то по сути каждая итерация это одна операция. предположим что скрипт может экстренно завершиться по таймауту или при падении мускуля из-за нагрузки и т.п. сам битрикс для таких вещей предоставляет функционал постраничных запросов к БД. если у вас каталог товаров на сотни тысяч элементов или на миллионы, и вы попытаетесь одним запросом собрать в массив миллион товаров чтобы их в цикле обработать, обычные сервера упадут от таких запросов и ничего не выполнится. для этого у битрикса есть параметры постраничной навигации для гет-запросов. например что делаю я в таком случае - я запускаю скрипт вручную на N элементов каталога и смотрю время выполнения. если за 10 секунд обрабатывается 100 элементов, можно написать для крона запрос который берёт на одной странице 300 товаров, обрабатывает их, а при успешном завершении записывает параметр страницы в set option, или в файлик, не важно. в общем сохраняет номер следующей страницы. и при последующем запуске скрипта он на вход получает номер этой страницы. и так за одну итерацию он обрабатывает 300 товаров последовательно. если вдруг в процессе работы скрипт упал и не завершился, страница не будет обновлена и при повторном запуске скрипта он возьмёт повторно эту же страницу. что касается обработки тяжёлых json, это я тоже делал, есть библиотеки на PHP которые позволяют считывать json так же постранично. так нагрузка на сервер не прыгает и ничего не падает и всё надёжно работает. преимущество такого подхода в том что сервер не испытывает нагрузок и работает стабильно для пользователей в том числе.
Тут вы описали просто итерационный метод, тот же прогресс бар работает по этому же принципу: запустили ручками контролер-скрипт, а дальше он каждый раз запускает нужный исполняющий-скрипт который что то делает, пока не случается какое то финальное событие или все данные не будут обработаны. Опять же Битриксовская "постраничка", это всего лишь ограничения по LIMIT для MySQL запроса. Понятное дело, когда мы говорим скрипту брать не 10 000 000 записей из таблицы а 100, он отработает быстрее. Но при этом, что плохого, если у тебя сервер может за раз без особых затрат брать много или к примеру отрабатывать долго? Т.е я понял первоначальный посыл/совет, что если пыховский скрипт работает пару часов, это плохо, архитектурно надо стремиться писать его "операциями по 30 секунд" ) поэтому и стало любопытно, что подразумевается под операциями, т.к бывает, что в том же методе, который описали вы, одна итерация может отрабатываться по 20 минут или час и ничего с этим не сделаешь, кроме как улучшать сервер. Поэтому стало любопытно, как так операциями работать ) Спасибо за ответ.
у меня сервер обычный. и при попытке загрузить в память гигабайтный json всё падало. вполне вероятно что я просто не умею это оптимизировать. и поэтому мне админы подсказали что лучше делать скрипт которому не требуется долго работать. и мне это помогло.
Т.е тут был стандартный итерационный подход типа: запускали ручками или по крону скрипт, тот загружал json на сервер , дальше обращались к нему, брал кусочки по 10-200 записей, записывали в ИБ, и так пока весь json не будет отработан? А как в самом начале пытались делать?
Обсуждают сегодня