если ляжет мастер процесс - ляжет все

потому мастер процесс не должен делать вообще ничего

и все делигировать воркерам

тогда шанс падения будет существенно ниже

чем тупее тем лучше

но не в этом дело

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

и ждет пока какой-то воркер возьмется его обрабатывать

направление взаимодействия в другую сторону, легко делать zero-downtime деплойменты

не надо делать супервизор - можно юзать любой готовый

короч тебе не нравится мастер процесс на пыхе?)

например я планирую юзать тупо docker демон как супервизор

короч тебе не нравится мастер процесс на пыхе?)

не, это не важно

мне не нравится тот факт что у процесса смешана зона ответственности, он и процессами рулит и http парсит

ну и я хочу go потыкать

как раз задачка

ну php-fpm также работает)

но мне больше всего нравится в этой схеме то, что у тебя этот вот http сервер может быть на одной машине

а воркеры на другой

ну php-fpm также работает)

как php-pm

да

а моя штука будет по другому

между http и приложением будут ходить тупо psr-7 запросы/ответы

без http

сериалайзить будешь просто?

ну тип того, еще не уверен на 100%

это детали

ну и еще мне нравится идея этой "очереди" запросов

но я на 100% не уверен потому вбрсил сюда)

давай лучше придумай почему мой вариант говно

сложна

ну пока существенный минус это то что это все еще два разных контейнера

ну то есть я не могу тупо завести один контейнер с приложением и не париться

всеравно нужно что-то сверху что будет http обрабатывать

модель работы та же что у php-fpm но с очередью запросов и возможностью воркерам самим существовать и рулить тем как они живут

вечно, умирают после запроса, умирают после 10-ти запросов

еще из минусов - если процесс будет умирать после каждого запроса, то это будет вынуждать "рождать" процессы (то что фиксит php-fpm)

плюс - штуки вроде "поработать после респонса" появляются автоматически

минус - php неудобно профайлить

надо бенчмарки подумать сделать

ну мол fpm vs symfony cli

если выхлоп будет и будет сильный - стоит имплементить

p.s. php-pm требует php-cgi которого нет официально в докерах и с php-cgi плохо работает opcache/apcu - не юзает шаред мемори

а зачем тебе опкеш для cli?

ну так... хотелось как-то получить буст от общей шаред мемори но я так понял что этого не получится

ну там буферы для строк всякие

но это только в fpm судя по всему

надо погонять бенчмарки короч

бо мне лично интересно

еще можно uwsgi попробовать

@fes0r Мне подумалось, что было бы круто такой демон, который форвардит воркерам сделать модулем nginx.

Ну, одну из реализаций демона. Чтобы nginx готовил объекты под PSR-7 и в приложение отдавал.

https://hub.docker.com/r/devtheops/php7-uwsgi/

вот еще интересный подход

для тех кто не хочет тащить nginx/php-fpm

ну мол все приложение в одном контейнере

особенно полезно тем кто хочет деплоиться на aws ecs и юзать тупо лоад балансер

почему просто не взять spring boot, который собирается в одну jar вместе со встроенным веб сервером и без всякого головняка?)

почему просто не взять spring boot, который собирается в одну jar вместе со встроенным веб сервером и без всякого головняка?)

тем что это не php?)

а переписывать текущее приложение под kotlin как-то не удобно... хотелось бы но чет лень

а как ты через очереди будешь хендлить запросы?

в смысле?

ну там не совсем очереди

скорее отложенная обработка... типа как лоток в конвеере - туда складываются запросы и ждут что положат ответ

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

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

ERROR: S client not available

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

тип того да

общение через zeromq

ну эт уже такое. хоть сокетами)

ну по сути это и есть сокетами, просто с удобной оберткой

я правда хз как оно по памяти будет

что "оно"?

обработка запроса

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

ну вот с этим особо проблем нет

ну мол после каждого респонса проверять открыт ли коннекшен (вдруг закрылся) и ресетить entity manager

флашить всякие монологи

свифтмэйлеры

следить что бы requestStack был пустым

чистить TokenStorage

что там еще может подтекать

сессии отрубить к чертям

во вы замороченные =) Сергей а с чем связана цель этих ново велосипедов? задача такая встала или просто ради эксперементов?

все ради скорости)

во вы замороченные =) Сергей а с чем связана цель этих ново велосипедов? задача такая встала или просто ради эксперементов?

Ну сейчас в PHP почти всё работает так, что дохнет после каждого запроса и бутстрапится при каждом новом. Хотя уже давно практически все языки-конкуренты поднимают процесс, который обрабатывает запросы и не выгружается из памяти необходимые данные между ними.

Да, любопытно что можно выжать из php

Плюс тот же Symfony считают одним из самых медленных фреймворков. Хотя в других языках есть и более тяжёлые решения, просто они не перезапускаются постоянно.

Плюс тот же Symfony считают одним из самых медленных фреймворков. Хотя в других языках есть и более тяжёлые решения, просто они не перезапускаются постоянно.

"считают" != "он такой есть"

симфони сам по себе если ты выкинешь все что там не надо очень даже шустрый

или например взять ту же доктрину - если ты юзаешь свои гидраторы ты можешь выборки ускорить раза так в 2-3

Ну вот флекс обещает упростить эту процедуру :)

Ну вот флекс обещает упростить эту процедуру :)

ну оно и сейчас не особо муторно на самом деле)

симфони сам по себе если ты выкинешь все что там не надо очень даже шустрый

А что можно выкинуть?) из коробки

А что можно выкинуть?) из коробки

начни с форм

берешь и выкидываешь

потом удаляем всякие ненужные листенеры

твиг)

твиг я оставил для profiler-а