app- имя нашего приложения, если очередь обслуживает кучу проектов
tenant - имя нашего покупателя - клиент который установил у себя наше приложение, если мы не глобально делаем, а для компаний
module - агрегат в проекте. booking/social/accounting/payments и тд
task - изначально тасков нет, но появляются по мере доработки тз и появления многоэтаповых задач
Что ты хочешь там увидеть... это ж не сварка двух изделий. Если тебе интересно как они думают - ты тут спрашивай или пиши в телегу. Или логика вышла с планеты Земля год назад?
Есть очередь 'commands.booking', туда могут прилетать тысяча команд типа "commands.booking.post.123" или "commands.booking.put.123", пусть будет - в час.
Разгребать одним воркером (под воркером я понимаю скрипт-демон) эту очередь - это бред. Разгребать в параллельке сотней воркеров - бред еще больший.
Идея как бы в том, чтобы один воркер (диспетчер) читал очередь по 10-15 записей и раскидывал её на исполнители, желательно параллельные.
И поднять 10 демонов, чтобы все присосались в очередь и конкурировали кто быстрее считает пришедшее сообщение, а то того и гляди считают вообще все, очередь то не редисовая, а хранит "последнее" пока вручную не пометишь в "обработано", это ерунда полная.
Демон 1, исполнителей - куча. Исполнители все не опишешь же докер файлами. Демон можно описать. А параллельку?
А ещё сегодня попробовал запустить тесты из пхпшторма на их дредноуте, оно не пошло. У них оказывается тесты выполняются только из мейк-файла, иначе никак (причем никто не знает почему из мейкфайла, просто оно сработало как-то, так и запомнили). С целью это спросить - я решил ему позвонить. "Почему?" - "Потому что мы так работаем!" Эти МЫ уже просто в каждой компании, так устал...
Я вызвонил его на мит, он сказал "запушить в ветку", на вопрос "так оно же еще не работает" - услышал "ничего страшного".
Когда запушил - был унижен, что мол мой код это монолитовский код, а код правильный это не монолитовский, но какой - он показать опять не смог.
Было много демагогии на тему
"я хочу чтобы ты был членом команды"
и "в нашей стране так не работают",
и "я же вчера сказал тебе, что я от тебя хочу",
а потом "я хочу чтобы код был минимально возможным",
а потом "понимаешь, я хочу чтобы твой код работал на той платформе что я тебе дал",
а потом что код должен быть "как в ларавеле, потому что всем так удобно",
а потом "что он не хочет меня обидеть, просто я сам это неверно понимаю"
При всем при этом я постоянно задаю вопрос "покажи что ты хочешь" и постоянно снова и снова получаю набор риторики о том, что такое "умно", "красиво", "чисто" и бережно, но не вижу ни одного ценного слова в этих речах. Они не про код, а про какие-то моральные установки, которым нужно поверить, и как следствие "просто сделать свою работу".
Я сижу и слушаю этот противоречивый набор пустых и ненужных оценок и похоже, совершенно всё понимаю.
Докер контейнеры писал "кто-то" и "когда-то", работает "никак", времени ни у кого нет, баги исправляются путем "мне удалось", в глубину никто не лезет, "в пхп есть проблемы поэтому мы идем в GoLang" и "я обучал целые команды и 20 лет уже этим занимаюсь".
Прям тебе целый набор установок по списку "я читал хабр, поверил всему сразу, поверь и ты".
Вот если бы он еще мог словами объяснить что он хочет, то я бы поверил, что он 20 лет разных людей обучает. Я в жизни обучил 4 разработчика всего "от тракториста до мидла". И я блин понимаю, когда нужно объяснить другим языком. Но это обучало 20 лет целые команды и не может тупо пояснить чего хочет - всё я понял. Улыбаемся и машем до ближайшей фразы "почему ты просто киваешь но не делаешь" и забираем доки.
Спамим proc_open($cmd, $spec, $pipes) + stream_set_blocked($pipes[0], false)? Под них не пишут конфиги докеровские?
Или react/php + Loop::get()->run()?
Получается сие работает в рамках одного процесса, значит лимит памяти может исчерпаться по мере числа тредов, в этом беда основная? (лид сказал трабла, какая - ему пояснить не удалось, и мне не понятно, судя по вашему ответу - тоже траблы нет)
ky0, и снова риторика, которая не дает ответ на вопрос и пытается выехать на метафорах, что ответ был дан, просто я дурак. я признаю что дурак, иначе б вопрос не задал. Зачем вы продолжаете мне показывать, что я не знаю, когда я сам пришел и сказал не знаю - я бы спросил, но вот это уже я знаю.
Это вроде понятный вопрос, и метафоры тут не нужны.
Вопрос - какие особенности работы с хендлерами, когда используем докер, чтобы не повесить в синхронную работу диспетчер этих самых хендлеров, который является воркером?
Лид говорит, что спамить процессы в пыхе проблема, они дескать поэтому любят GoLang, потому что там это легко. Я пытаюсь понять почему в пыхе это проблема. Всё.
сергей кузьмин, то есть команды из 10 человек для которых нанимали моего лида, чтобы он им показал куда там нажимать, тратили полгода, чтобы вьехать в кубы, а вы предлагаете мне их побыстрому "посмотреть"???
я знаю что это неизбежно.
я пытаюсь понять принцип прежде чем изучать кубы. в этом и суть вопроса.
А, кажется уловил, сам по себе вызов proc_open() тоже синхронный. Стало быть если я даже в цикле сделаю пять раз proc_open() то выполняться будут по-очереди. А чтобы параллельку сделать как-минимум придется подключить react/async либу. Но это не про докер, это и в самой пыхе так.
А вопрос поднять третий процесс по прежнему вопрос - в докере это как-то иначе делается, чем просто вызвать proc_open из worker-диспетчера, пусть даже в React\Async\parallel() ?
Román Mirilaczvili, Пока на самом деле не знаю откуда там проблема, мне лид сказал.
Если бы я делал примитивную очередь на редисе, я бы в коде своего контроллера подрубился к очереди редиса, отправил сообщение. До этого я бы написал консольную команду для пхп приложения, которая запускает while (true) и в середине в каждом шаге с паузами по 1 секунде проверял бы что там в очереди пришло не пришло, обрабатывал и возвращал бы результат. Если результат косяковый или кривой - добавлял бы исходное сообщение обратно в очередь, чтоб повторить (как с курлом, если неверный ответ, просто запускай курл еще раз с другой проксей например). Современные очереди типа Nats уже умеют в Consumer, который по сути точка слива сообщений, где они хранятся и сами перезапускаются если нет подтверждения "обработано", но смотрим дальше...
При этом (предположим приложение безбраузерное, а только консольное) - я бы сначала выполнил команду "подыми воркер", потом выполнил команду "сделай действие". ВОРКЕР (висящий) зацепил бы сообщение, полученное из КОМАНДЫ и вот тут магия - ЗАПУСТИЛ БЫ ТРЕТИЙ ПРОЦЕСС (в смысле - нам что, надо копировать Dockerfile зачем-то здесь?) избегая простоя от синхронного выполнения.
Отчего фраза лида "там есть проблема" приобретает смысл на тему "чтобы третий запустить" - там получается третий докер файл должен быть, по которому выполняется не просто "php child.php", а "docker exec" ? То есть по сути зачем докер файл если это разовая операция, сделал, ответ получил, потушил, не надо там демон никакой.
То есть если слушатель подымается в начале, команда - вручную либо если браузер - то из nginx, то откуда берется третий, когда докер? В обычных условиях я бы внутри второго воркера сделал бы proc_open и поднялся бы новый процесс, хоть 100 процессов. Но если я правильно понял ПРОБЛЕМУ, то работая в докере так нельзя?
Román Mirilaczvili, ты чтобы 100 заказов обсчитать 100 файлов Dockerfile копируешь и запускаешь по одному? Причем тут рутина? Из дочернего процесса создавать родительский проблема, а не файлы копировать блин
Идея то в чем в итоге? На каждый обработчик пишем один докер файл и подымаем по нему процесс? Плюс один главный докерфайл для воркера-диспетчера, который будет их подымать реагируя на входящее в очереди?
Условно если я хочу поднять 5 очередей, то на каждую очередь пишу докерфайл, потом запускаю 5 процессов и каждая из них пошла работать со своей очередью, так?
Если подумать - то в ноутбуках когда делается единый вход для наушников-микрофона - разьем содержит столько-то пинов. И существуют переходники, которые позволяют соединить зеленый и красный в один для ноутбука. Может если взять такой переходник и воткнуть гитару в красный, а сам переходник в телефон - косяка не будет?
Может я немного слабоват в этом, но почему блок питания P (а не Z) а материнская плата B (а не Z) при таких злющих процессоре и видео? Оператива тоже смотрю с тиками 15-16, вполне себе крутая.
Диск 240гб... это мало.
Если ты в компьютерный клуб комп собираешь - пойдет наверное, пара игр и всё, но для личного пользования даже 500 не всегда адекватно, постоянно приходится удалять лишнее, а не дай бог есть игры, которые криво работают с памятью и захочется выделить раздел под подкачку ещё... Ты просто поставишь один раз FarCry6 или Cyberpunk, это 100 гигов, понимаешь? Одна игра с открытым миром - 60-100 гигов.
Существует разница между задать роут каллаблом и строкой.
Каллабл требует обьект, объект требует use, use требует autoloader, autoloader хочет тики процессора, чтение с диска и память. Пока роутов 10 - бог с ним. Но когда роутов полтысячи - там use только штук 50. Это много.
Строка в этом плане лучше, т.к. подгрузка класса произойдет только в момент когда будет резолвится Route::namespace().
Кроме того когда мы задаем каллабл массивом - это считается статическим методом. Если мы хотим создать динамический - в первый параметр каллабла обьект надо. И когда мы пишем свой инжектор зависимостей мы вдруг понимаем, что нет такой формы записи, чтобы отличать статику от динамики, но при этом не передавать объект, и запись через собаку кажется вполне разумной.
Разве что в ларе 8 и более сделали чтобы если первый параметр класс - то автовайрить его и создавать, нарушив немного идею каллабла, то может быть, но по факту с этим есть трабла на уровне пыхи.
====
Я думаю что у ТС нужно вызвать `php artisan optimise`
Да, и в статье про принудительную помощь психиатра есть пункт "если человек вредит себе или окружающим". Интересно получается, если я рассказываю бедным как нагибают богатые - это вред богатым правда? Значит меня нужно в дурку. Все правильно.
И хватит уже делать множественное число в именах таблиц. Это вам ничего не дает, кроме ощущения, что "как в документации". Называйте таблицу так же как модель, только в lower_snake_case.
Это не ответ, это рекомендация, которая работает.
Единственное позволяет писать
->belongsTo(Model::class)
->belongsToMany(Model::class)
А множественное это постоянное обращение на класс инфлектора, и обратно, мешающее и генерации кода (автоматическому созданию новых классов) и дающее лишнюю нагрузку на каждом скрипте.
events.([app].)?([tenant].)?[module]
events.([app].)?([tenant].)?[module].([task])?
app- имя нашего приложения, если очередь обслуживает кучу проектов
tenant - имя нашего покупателя - клиент который установил у себя наше приложение, если мы не глобально делаем, а для компаний
module - агрегат в проекте. booking/social/accounting/payments и тд
task - изначально тасков нет, но появляются по мере доработки тз и появления многоэтаповых задач
Прошу подтвердить или опровергнуть.