Laravel по-русски

Русское сообщество разработки на PHP-фреймворке Laravel.

Ты не вошёл. Вход тут.

#1 27.06.2017 11:52:01

Очереди

Добрый день.

У кого-то есть опыт использования очередей на shared хостингах? Как решали контроль работы слушателя задач, например, если хостер прибьет задачу?

Единственно, что придумал гарантированно запускать задачи - cron + artisan schedule:run, в kernel смотреть - есть ли записи в jobs, если есть - запускать команду `queue:work --once` по количеству задач в таблице. Но это как мне кажется то еще решение...

В сети предлагают планировщиком запускать

$schedule->command('queue:work --daemon')->everyMinute()->withoutOverlapping();

Но если прибить руками (kill -9) задачу она все-равно будет числиться в кеше и не перезапустится. Нужен совет. Советовать уйти от шаринга - бесполезно, я уже несколько недель пытаюсь убедить заказчика.

Не в сети

#2 27.06.2017 14:33:11

Re: Очереди

вариант с QUEUE_DRIVER=sync не канает?

Не в сети

#3 28.06.2017 04:53:01

Re: Очереди

sync - сразу же выполнять задачи очереди, так?

Отправить почту на несколько адресов, создать лида в CRM занимает по времени где-то 3-5 секунд (AmoCRM почему-то долго отрабатывает). Заставлять пользователя ждать 5 секунд - не очень правильно.

Не в сети

#4 28.06.2017 08:34:14

Re: Очереди

ну на шаред-хостинге сложно выкручиваться из таких ситуаций. как вариант могу предложить по крону запускать не 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 но вызывать обработку на аяксовом запросе и, зная примерно сколько времени такая обработка занимает, даже показывать пользователю прогресс-бар. ему всё-таки придётся ждать, но по крайней мере у него будет визуальный фидбэк для операции

Не в сети

#5 28.06.2017 10:09:28

Re: Очереди

Благодарю, я тоже к третьему варианту склонялся, но все-же надеялся на чудо smile

Не в сети

#6 28.06.2017 11:44:33

Re: Очереди

в случае с шаредом – чудом является то что можно получить нормальное продакшен-окружение с нулевыми затратами на администрирование и – за смехотворные деньги… smile всё остальное – увы smile

ps. это тебе ещё повезло что на хостинге exec не отключен для пхп. многие – отключают и его и все прочие функции, позволяющие создавать новые процессы…

Изменено constb (28.06.2017 11:45:35)

Не в сети

#7 29.06.2017 02:19:57

Re: Очереди

Есть ещё «эмуляция» cron’а через HTTP. Я когда-то даже видел такой сервис — регистрируешься и каждые N минут тебе прилетает HTTP-запрос, по которому твой скрипт уже выполняет свои задачи. На мой взгляд, лучшее решение — настройки не требует, работает как обычный скрипт на обычный запрос.

Не в сети

#8 29.06.2017 07:56:19

Re: Очереди

Есть ещё «эмуляция» cron’а через HTTP

по-моему так все делали когда-то smile плюс – в том что такой скрипт выполняется в контексте веб-сервера. если используется какой-нибудь xcache или apc для хранения данных, команднострочным скриптам до него достучаться нереально – только через апач. но и минус тоже есть – на работу скрипта накладываются ограничения на время жизни запроса из max_execution_time и из настроек веб-сервера. не успел отработать – считай не повезло smile

в этом плане то что в ларавеле есть из коробки всё для написания команднострочных команд, очередей задач и встроенный крон – это конечно великое дело! но ставить проект на ларавеле на шаред-хостинг?… вот честно – никогда так не делал, и даже не собирался. учитывая сколько сейчас стоят VPS на digitalocean (для интернациональных проектов) или на timeweb (для российских) – вообще по-моему нет смысла связываться с шаредами.

самое печальное в том, что реально дешёвые шареды при этом исключительно тормозные, а те, на которые выделяется достаточно ресурсов чтобы они летали – стоят дороже чем VPS!

Не в сети

#9 29.06.2017 11:34:02

Re: Очереди

но и минус тоже есть – на работу скрипта накладываются ограничения на время жизни запроса из max_execution_time и из настроек веб-сервера. не успел отработать – считай не повезло smile

Мы же говорим про shared - здесь не то что ограничения по max_execution_time стоят (+ таймаут в самом nginx), наверняка отключена половина функций (вроде phpinfo, ага), стоит низкий memory_limit и т.д. Лучше хоть так, чем никак. Работу скрипта можно разбить на отрезки и в следующий вызов продолжить с места, где последний прервался.

но ставить проект на ларавеле на шаред-хостинг?… вот честно – никогда так не делал, и даже не собирался.

Согласен, это извращение. Чудо, если он вообще имеет все нужные расширения.

самое печальное в том, что реально дешёвые шареды при этом исключительно тормозные, а те, на которые выделяется достаточно ресурсов чтобы они летали – стоят дороже чем VPS!

Так это как некоторые VPS стоят дороже выделенных серверов, имея при этом плохие характеристики. Видимо, берут деньги за "отказоустойчивость и облака" (на практике однако такие VPS обычно ломаются ничуть не реже выделенных).

Не в сети

Подвал раздела