ну с учетом того что под php-pm есть готовый Dockerfile то подводные камни в целом те же что и для других вариантов всяких воркеров - кто-то из твоих сервисов может активно гадить в память, не быть преспособленным к тому что в пределах жизн ипроцесса может быть два+ запроса и т.д.

Т.е. получается нужно при использовании php-pm сервисы писать stateless, без сайд-эффектов?

Так всё в кучу: $service = new ActivateService($repo, $user, $date); $service->activate(); Сервис мутабельный, в контейнер без фабрики не запихнёшь. А так с разделением: $service = new ActivateService($repo); $service->activate($user, $date); Теперь иммутабельный и переиспользуемый.

Я имел в виду что-то типа этого.

Т.е. получается нужно при использовании php-pm сервисы писать stateless, без сайд-эффектов?

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

просто ты уходишь от удобной для новичков модели "мой процесс изрлирован от других и в целом он обрабатывает один запрос и потом умирает" к "воу теперь мой процесс может обрабатывать несколько запросов и мне надо чистить после запроса что бы на следующий никак не влиять"

хотя опять же ты можешь просить php-pm убивать воркеры после каждого запроса, просто это будет.... не так эффективно

всеравно эта модель проще чем "мой процесс может обрабатывать несколько запросов одновременно и потому мне важна изоляция эффектов на уровне приложения"

> нет, система без сайд эффектов не может делать ничего полезного. полностью stateless тоже (можно привязывать к запросу стэйт) Ну да, я типа и имел в виду, что поведение сервиса должно быть детерменированно, что не должно после запроса остаться в его состоянии какой-то хрени. > всеравно эта модель проще чем "мой процесс может обрабатывать несколько запросов одновременно и потому мне важна изоляция эффектов на уровне приложения" Ты про модель просить убивать воркеров? А вообще, думаю нужно покопаться в исходникакх и попробовать покрутить эту штуку, тогда уже станет всё понятнее.

> Ты про модель просить убивать воркеров? нет, я про варианты с event loop (reactphp, amphp)

В исходниках копаться не стоит))) понятнее точно не станет)

> А вообще, думаю нужно покопаться в исходникакх и попробовать покрутить эту штуку ты когда-нибудь писал консьюмеры очередей на php?

> А вообще, думаю нужно покопаться в исходникакх и попробовать покрутить эту штуку ты когда-нибудь писал консьюмеры очередей на php?

Нет.

php-pm это простой менеджер процессов. Он тебе поднимает твое приложение в отдельных воркерах. Дальше твое приложение должно уметь после обработки запроса принять новый. Или нет. В этом случае процесс умрет и поднимется новый

если хочешь побаловаться - попробуй написать CLI скрипт, сделать папочку с запросами (файлики) и пусть твой скрипт будет рандомом файлики на вход принимать

php-pm это простой менеджер процессов. Он тебе поднимает твое приложение в отдельных воркерах. Дальше твое приложение должно уметь после обработки запроса принять новый. Или нет. В этом случае процесс умрет и поднимется новый

так это вообще реально на пхп со сколько нибудь существенной нагрзукой? имею ввиду потенциальную проблему с утечкой памяти, если процесс будет как демон висеть не умирая

Еще вопрос что считается обработкой запроса. Если речь про всякие реакты/ампы, всё будет сложнее

так это вообще реально на пхп со сколько нибудь существенной нагрзукой? имею ввиду потенциальную проблему с утечкой памяти, если процесс будет как демон висеть не умирая

если руки из жопы то нет, а так нет никаких проблем

так это вообще реально на пхп со сколько нибудь существенной нагрзукой? имею ввиду потенциальную проблему с утечкой памяти, если процесс будет как демон висеть не умирая

Неделями работает демон, лопатит огромные документы и не жалуется

Еще вопрос что считается обработкой запроса. Если речь про всякие реакты/ампы, всё будет сложнее

ну я о том и говорю, схема работы php-pm вообще не подразумевает перепись приложения, оно просто должно после себя чистить. А всякие ayres/reactphp там придется пул коннекшенов вводить к базе, сложнее с зависимостями и т.д.

это обычно не по зубам среднестатистическому php-нику.

У ампа пул под постгрю есть, тут проще все

давно его не тыкал

У реакта нету, вроде

я лучше на go каком такие штуки писать буду. Не потому что на php нелья а потому что вжопу php

Прочего и не ожидал))

не ну хотя бы ради разнообразия.... уж больше 10-ти лет пишу на пыхе, и только парочка проектов на бэке была не на нем....

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

а какие плюсы вообще от того что процесс висит? не тратиться время на инициализацию?

бутстраппинг, да

я где-то видел бенчмарк запуска симфы на php-pm

а вот когда процесс висит в памяти он какие-то ресурсы же тратит? т.е как минимум память занимает + процессорное время на "слушание" входящих запросов

у меня по этой теме вообще пробел жирный,(потоки, процессы, асинхронность и т.д) всё собирался таненбаума прчоитать но так и не дошел

а вот когда процесс висит в памяти он какие-то ресурсы же тратит? т.е как минимум память занимает + процессорное время на "слушание" входящих запросов

"слушанье" не тратит процессорные мощности (спасибо системным штукам вроде select/epoll). Память то что жрется - ну и ладно

ну то есть если у тебя 1 запросв час то php-pm тебе явно не нужен, а если запросов 100 в секунду то....

можно нехило так лэтенси запросов оптимизнуть

"слушанье" не тратит процессорные мощности (спасибо системным штукам вроде select/epoll). Память то что жрется - ну и ладно

а как оно работает? Т.е есть порт, и есть какаяя то функция типо isRequestNow которая вызывается дохрена раз в скунду?

не в плане php-pm а вообще

Epoll загугли

а как оно работает? Т.е есть порт, и есть какаяя то функция типо isRequestNow которая вызывается дохрена раз в скунду?

попробуй написать свой ping сервер, это весело, занимает не много времени и ты больше будешь понимать как все это работает

типа простой TCP сервер который слушает коннекты и отправляет обратно то что прислали.

это такой вот hello world для сетей

(пишется в строчек 10-20 на php)

Здравствуйте. Хочу задать примитивный вопрос (https://toster.ru/q/50496) о том, кто-как выносит зависимость контроллера от ема.

Есть вариант с оборачиванием в сервис с транзакцией, но не уверен, что это лучший вариант.

Есть вариант с оборачиванием в сервис с транзакцией, но не уверен, что это лучший вариант.

сейчас человек который задавал этот вопрос на него же и ответит

Я надеялся на это, когда скидывал вопрос на тостере, ответа там так и не дали в принципе =)

Есть вариант с оборачиванием в сервис с транзакцией, но не уверен, что это лучший вариант.

Это как? Сервис в котором будет делаться flush - ?

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

Например это https://github.com/schmittjoh/JMSAopBundle/blob/master/Resources/doc/index.rst

А чем для тебя плохо делать flush в контроллере?

а всю работу с em в сервисах?

Точнее в репозиториях

АОП норм штука, но нужна ли она для твоих текущих операций

Мне просто высказали фе после код ревью, но не сказали чего хотят там увидеть, вот у меня и появились сомнения.

Аргументы почему фе были вида "контроллер ничего не должен знать про ем, это не его облать ответствености".

я так до конца и не понял подход доктрины

на текущем проекте "флаш" делается в репозитории

я так до конца и не понял подход доктрины

https://martinfowler.com/eaaCatalog/

т.е два варинта: если нормлаьный код, то в апликейшен сервисы инджектятся репозитории, в которые инджектятся маперы ну или если быстрокод без норм модели, то просто что то типо маперов(а по факту обертка над sql и прочим) индежктится в сервис и оттуда вызывается

https://martinfowler.com/eaaCatalog/

да спасибо, эт я знаю) но я вот не могу понять, Entity Manger это что такое зачем он нужен?

Аргументы почему фе были вида "контроллер ничего не должен знать про ем, это не его облать ответствености".

а чья?

да спасибо, эт я знаю) но я вот не могу понять, Entity Manger это что такое зачем он нужен?

для меня выглядит как лишнее звено

ERROR: S client not available

да спасибо, эт я знаю) но я вот не могу понять, Entity Manger это что такое зачем он нужен?

управление unit of work и identity map

а чья?

Не сказали, вот тут и интересуюсь

Аргументы почему фе были вида "контроллер ничего не должен знать про ем, это не его облать ответствености".

хотя щас вот вспомнил у нас некоторые все таки делают, флуш или в репозитории а некоторые в обработчике команды, что можно считать почти контроллером

да спасибо, эт я знаю) но я вот не могу понять, Entity Manger это что такое зачем он нужен?

https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/EntityManager.php#L352

вот посмотри сюда и посмотри на паттерны

вот посмотри сюда и посмотри на паттерны

не смотрите дети паттерны

Аргументы почему фе были вида "контроллер ничего не должен знать про ем, это не его облать ответствености".

контроллер должен знать о том что надо зафлашить изменения, он же контроллер. Другой момент что EntityManager слишком жирный сервис и иногда хочется изолировать только flush

можно не изолировать и навесить какой-нибудь анализатор который будет следить что никто в контроллерах ничего кроме flush не вызывает

ну то есть смысл в том что бы кто-нибудь не замутил в контроллере $em->createQueryBuilder() и пошел в пляс

хотя на маленьких проектах даже это может быть оправдано

p.s. у меня необходимость вводить отдельный сервис который флашит изменения связаны с тем что у меня 2 unit of work))))

типа доктрина + еще одна хрень, и мне надо в определенном порядке действия между двумя флашами делать.... потому я это изолирую в сервис отдельный

а так обычно мне лень, хотя опять же дело на 1 минуту

То есть если не злоупотреблять, чисто flush не таки плох. В принципе точно так же с командами и всякими джобами?

То есть если не злоупотреблять, чисто flush не таки плох. В принципе точно так же с командами и всякими джобами?

Да, не так он и плох, но сама схема не очень, и лучше конечно nginx + php-fpm и отвечать встроенными средствами.

Заодно и процесс не помрет после завершения работы.

управление unit of work и identity map

так и не понял зачем это из репозитория выносить...

так и не понял зачем это из репозитория выносить...

Потому что это общие зависимости всех репозиториев?)

но они не всегда же нужны

Если ты работаешь с сущностями, то всегда

я к тому что некоторые бизнес действия укладываются в одну операцию... Получили конкретную модельку по id, изменили поле. Зафлашили.

кстати, я понял, почему Repo Pattern & UOW - отстой

хах, а ну, поведай

особенно UoW

он подерживает 2 и более базы данных?

одновременно

он еще минет по утрам не делает. Согласен, UOW отстой

зачем он вообще тогда нужен?

я к тому что некоторые бизнес действия укладываются в одну операцию... Получили конкретную модельку по id, изменили поле. Зафлашили.

И вообще флаш у нас идёт в репозитории методом save

зато оченЬ хорошо делает BDSM