Использовать ли sleep() в громоздком php-скрипте?

Это смотря какие настройки на сервере, у меня дома можно все, макс объемы памяти и процессор грузит только на 50 %. Если бы у меня был рабочий сервер. Я бы так настроил, что он бы даже не дернулся.

дк протестируйте сами. возьмите этот скрипт, наставьте слипов, включайте и смотрите на нагрузку.

но имхо это тупой вариант. set_time_limit не распространяется на sleep() и обычно вроде нагрузка на CPU исчисляется в час(на моем например) так что вам долго придется в слипах сидеть. Но это тоже не вариант, т.к. скрипт будет оперативную память все это время тупо сжирать.

так бы сразу и сказали - через задницу

Подобные вещи делаются скриптом легким скриптом + кроном

Пока скрипт находится в sleep-е, время выполнения не тикает.

Т.е. в системе может может быть жёстко установлен лимит 30 секунд, и при этом ваш скрипт может находиться 10 минут в sleep-е и 1 секунду что-то делать.

Процессорное время тоже не должно при этом считаться.

лучше по крону кусками

Нужно взять и попробовать на конкретном хостинге, я только что у себя проверил - время пребывания в sleep() учитывается как время выполнения скрипта, тоесть входит в 30 разрешенных секунд. Но, интересно, что если эти же 30 секунд установить с помощью функции set_time_limit(30), то тогда время в sleep() не учитывается. Еще если с помощью set_time_limit() не удастся установить необходимое время, то это можно обойти запуская из одного скрипта другой.

Это уже какие-то премудрости вашего хостинга )

Вообще, это работать не должно, ибо по прошествии отведенного времени, убивается родительский процесс и все его потомки.

Но даже если такое где-то сработает, то за это могут напинать ))

time_limit в php - общий с учетом всех задержек на уровне php.

вот RLimitCPU, который тоже устанавливают хостеры (в apache RLimitCPU или командой ulimit) - чистое потребленное процессором время.

Также погуглите что такое форк-бомба - все лимиты обходятся.

ТС, честно, возьмите ВДС и не мучайтесь )

Не всегда. У ТС хорошее решение для некоторых случаев. Например, если у него действительно мощный тяжёлый скрипт, который раз в десять секунд из файла подкачивает лог обновлений со статистикой в базу и агрегирует новые данные с предыдущими значениями. То есть он на основе изменений за последние секунды перестраивает табличные кеши со статистическими данными. Вот тогда время закачки и пересчёта данных в разы меньше времени подсоединения к базе. Более того, время прекомпиляции скрипта может в десять-двадцать раз превышать время выполнения самого скрипта. За эти постоянные компиляции и с хостинга могут пнуть.

Кроме того, иногда в памяти скрипта полезно держать некоторые данные, которые значительно ускоряют процесс, а не запрашивать их при каждой итерации. Например, так хорошо держать данные из справочных таблиц. Я уже молчу про то, что в кроне минимальный интервал запуска - минута. Если нужно обновлять статистику значительно чаще, то крон в качестве рестартёра каждого цикла не выход: нужно по крону постоянно перезапускать скрипт плюс гасить его предварительно из самого же скрипта через exit и, для гарантии, через аварийную скриптобойку вроде set_time_limit (59). Механизм опробован, механизм работает в боевой системе, правда не на шареде 🍻

В общем, не вижу никаких проблем в постановке и решении задачи. Вопрос в том, как её решать имеющимися средствами. VDS всё-таки штука тормозная и если это интернет-магазин, то аренда VDS не выход.