Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
Страницы 1
Добрый день.
У кого-то есть опыт использования очередей на shared хостингах? Как решали контроль работы слушателя задач, например, если хостер прибьет задачу?
Единственно, что придумал гарантированно запускать задачи - cron + artisan schedule:run, в kernel смотреть - есть ли записи в jobs, если есть - запускать команду `queue:work --once` по количеству задач в таблице. Но это как мне кажется то еще решение...
В сети предлагают планировщиком запускать
$schedule->command('queue:work --daemon')->everyMinute()->withoutOverlapping();
Но если прибить руками (kill -9) задачу она все-равно будет числиться в кеше и не перезапустится. Нужен совет. Советовать уйти от шаринга - бесполезно, я уже несколько недель пытаюсь убедить заказчика.
Не в сети
вариант с QUEUE_DRIVER=sync не канает?
Не в сети
sync - сразу же выполнять задачи очереди, так?
Отправить почту на несколько адресов, создать лида в CRM занимает по времени где-то 3-5 секунд (AmoCRM почему-то долго отрабатывает). Заставлять пользователя ждать 5 секунд - не очень правильно.
Не в сети
ну на шаред-хостинге сложно выкручиваться из таких ситуаций. как вариант могу предложить по крону запускать не queue:work а свой собственный раннер (свою команду artisan), который через ps auxww проверяет запущен демон или нет и стартует его при необходимости. ->withoutOverlapping() использует активный в системе CACHE_DRIVER, но не проверяет наличие процесса. (вообще кстати если CACHE_DRIVER установлен в null, array или cookie то ->withoutOverlapping() просто не будет работать)
ещё один вариант – поменять механизм работы ->withoutOverlapping() – он ищет в контейнере реализацию для интерфейса Illuminate\Console\Scheduling\Mutex – можно создать свой механизм блокировок, например через локи на файлах через flock(…, LOCK_EX) или опять же через ps auxww – в этом случае свой раннер будет не нужен…
третий вариант – отображать прогресс операции пользователю. оставить QUEUE_DRIVER=sync но вызывать обработку на аяксовом запросе и, зная примерно сколько времени такая обработка занимает, даже показывать пользователю прогресс-бар. ему всё-таки придётся ждать, но по крайней мере у него будет визуальный фидбэк для операции
Не в сети
Благодарю, я тоже к третьему варианту склонялся, но все-же надеялся на чудо
Не в сети
в случае с шаредом – чудом является то что можно получить нормальное продакшен-окружение с нулевыми затратами на администрирование и – за смехотворные деньги… всё остальное – увы
ps. это тебе ещё повезло что на хостинге exec не отключен для пхп. многие – отключают и его и все прочие функции, позволяющие создавать новые процессы…
Изменено constb (28.06.2017 11:45:35)
Не в сети
Не в сети
Есть ещё «эмуляция» cron’а через HTTP
по-моему так все делали когда-то плюс – в том что такой скрипт выполняется в контексте веб-сервера. если используется какой-нибудь xcache или apc для хранения данных, команднострочным скриптам до него достучаться нереально – только через апач. но и минус тоже есть – на работу скрипта накладываются ограничения на время жизни запроса из max_execution_time и из настроек веб-сервера. не успел отработать – считай не повезло
в этом плане то что в ларавеле есть из коробки всё для написания команднострочных команд, очередей задач и встроенный крон – это конечно великое дело! но ставить проект на ларавеле на шаред-хостинг?… вот честно – никогда так не делал, и даже не собирался. учитывая сколько сейчас стоят VPS на digitalocean (для интернациональных проектов) или на timeweb (для российских) – вообще по-моему нет смысла связываться с шаредами.
самое печальное в том, что реально дешёвые шареды при этом исключительно тормозные, а те, на которые выделяется достаточно ресурсов чтобы они летали – стоят дороже чем VPS!
Не в сети
но и минус тоже есть – на работу скрипта накладываются ограничения на время жизни запроса из max_execution_time и из настроек веб-сервера. не успел отработать – считай не повезло
Мы же говорим про shared - здесь не то что ограничения по max_execution_time стоят (+ таймаут в самом nginx), наверняка отключена половина функций (вроде phpinfo, ага), стоит низкий memory_limit и т.д. Лучше хоть так, чем никак. Работу скрипта можно разбить на отрезки и в следующий вызов продолжить с места, где последний прервался.
но ставить проект на ларавеле на шаред-хостинг?… вот честно – никогда так не делал, и даже не собирался.
Согласен, это извращение. Чудо, если он вообще имеет все нужные расширения.
самое печальное в том, что реально дешёвые шареды при этом исключительно тормозные, а те, на которые выделяется достаточно ресурсов чтобы они летали – стоят дороже чем VPS!
Так это как некоторые VPS стоят дороже выделенных серверов, имея при этом плохие характеристики. Видимо, берут деньги за "отказоустойчивость и облака" (на практике однако такие VPS обычно ломаются ничуть не реже выделенных).
Не в сети
Страницы 1