композиция) но это потом

а еще - раз уж там примеры с животными - может стоило и бабушку Лисков на минималках вспомнить

так вот, повторю вопрос

откуда у тебя возникла делать иерархию глубиной в 3 уровня?

там же по заданию 3 класса с общим предком

нет, там A WebDeveloper "is a" Person A WebDeveloper "is a" ComputerProgrammer

в моей картине мира я наследуюсь от того, в котором больше свойств/реализаций там это ниже по заданию для методов надо

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

сча дай задачку почитаю

ну так у тебя цепочка должна быть WebProgrammer -> ComputerProgrammer -> Person по условию

там подсказку тебе дают что после вызова parent конструктора надо еще кой чего сделать

Da

Ага)

Нужно откатить обнову...

Чет старый способ распознавания был получше

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

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

тут больше упирается в твой сервер и настройки ОС

мы когда нагрузочные гоняли t2.medium нормально переваривал где-то 15K соединений (с сервера раз в минуту бродкастило)

2 ядра и 4 ГБ ОЗУ, понимаю что будет больше расходоватся памяти, но на сколько? есть четкая тендения на одно соединение сколько то расходуется памяти?

мы когда нагрузочные гоняли t2.medium нормально переваривал где-то 15K соединений (с сервера раз в минуту бродкастило)

это без редиса? в качестве движка была память?

это с рэдисом но один инстанс

без рэдиса будет примерно одинаково

на вскидку сколько расходовалось памяти?

2 ядра и 4 ГБ ОЗУ, понимаю что будет больше расходоватся памяти, но на сколько? есть четкая тендения на одно соединение сколько то расходуется памяти?

ты можешь посчитать) напиши простенький нагрузочный тест если хочешь

на вскидку сколько расходовалось памяти?

вообще не помню... вот честно

помню что нас устраивало)

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

и скрипт который будет раз в M времени пинать центрифугу и просить забродкастить что-то в канал

я првильно понимаю параметры t2.medium: 4.0 GiB 2 vCPUs ?

да. правильно. Можешь интанс поменьше взять

понял спасибо

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

а если будет не хватать - поднять рэдис и сделать класстер не особо сложная задача

и не забудь чуть-чуть потюнить настройки

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

ну так тем более

https://fzambia.gitbooks.io/centrifugal/content/deploy/tuning.html

про настройки это я про это

и не забудь чуть-чуть потюнить настройки

а в 2-х словах можешь сказать на какие параметры стоит обратить внимание ?

как минимум не забудь ulimit поднять) а то грустить будешь

там по ссылке все что надо есть

Maksim помню ты рассказывал про CQRS и тп, а вы реализовывали у себя Process Manager ? И как разруливали саги и тп?

о) а я думал, как Сергею про саги напомнить :)

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

у меня наркоманская схема "любителей обмазаться команд басами" (с)

$sagaService = new SagaService( new SagaStore( new SagaInMemoryStorage(), new SagaSerializer() ) );

я так понял вы все же храните стейт процесса?

ага

у меня саги могут неделями жить)

хм, а всякии коллизии и тп? например юзер инициировал одну и туже операцию?

о, Максим нашел новую жертву)))

создается новый процесс?

сама нашлась) я тут не при чём)

ну да, прям как я)

о) а я думал, как Сергею про саги напомнить :)

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

создается новый процесс?

нипанимать. Это не проблема саги, на сколько я понимаю

хм, а всякии коллизии и тп? например юзер инициировал одну и туже операцию?

типа 2 раза зарегистрировался?

типа да

ну то есть ты хочешь что-то типа локов на уровне саги

типа "идентификатор - email, и он должен быть уникальным"

но по идее это не саги дело

ну эт не проблема саги всё же) хотя, мб и стоит блокировку реализовать

типа "идентификатор - email, и он должен быть уникальным"

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

начиная от саг и заканчивая бизнес логикой

ERROR: S client not available

ну по идее у тебя самый первый этап саги должен был "забить место" и тогда второй процесс упадет типа - зарегистрирован уже такой. нет?

можно через рэдис лочить операцию на корень

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

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

начиная от саг и заканчивая бизнес логикой

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

а саги... они хороши для заказов например. Поменял статус, провел платежку, подождал пока подтвердилось, поменял статус еще раз

(ну если мы об одном и том же проекте говорим))

ох, сейчас меня возьмут за неразглашение))

ну прост для регистрации саги - как-то круто дофига)

ох, сейчас меня возьмут за неразглашение))

у вас там запатентованые алгоритмы?

у вас там запатентованые алгоритмы?

алгоритмы регистрации)

@fes0r какой сейчас кейс: - авторизоваться как под мерчантом (роль 2, для этого нужно еще под ролью один зарегаться) - заполнить все поля и создать мерчанта - создать его кошелек (это делается частично на фронте), провалидировать - подтянуть доп инфу к кошельку - активировать мерчанта (чтобы он показывался везде где нужно) в принципе это сейчас сделано, через экшены и доменные ивенты, но на каждом этапе было 100500 интеграционных проблем, что-то не увидели, про что-то не знали и тп (как обычно)

ну и ты хочешь попробовать это в "процесс" запихнуть

что бы в одном месте весь флоу

что бы в одном месте весь флоу

тип того

нууу... прикол в том что ты можешь остановиться в этом флоу на любом моменте и потом типа ты должен продолжить с того места на котором остановился

и с точки зрения пользователя это будет... ок

ну так и есть

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

Maksim может быть есть мысли насколько описанное норм сагами описывать?)

я б не стал

ах, да

создание кошелька асинхронно)

создание кошелька асинхронно)

оно ж на клиенте

ну всё, раз асинк, точно саги)

создание кошелька асинхронно)

тебе ж уже готовый публичный ключ должен придти

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

а пользователь пока до конца не доберётся, ничё делать не может, кроме просмотра формы?

а пользователь пока до конца не доберётся, ничё делать не может, кроме просмотра формы?

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

но он может браузить каталог например или новости читать)

я не уверен что саги тут к месту...

хз даже) статус в бд короче обновлять и предлогать ему действия в зависимости от оного) саги не вижу :(

потом он может залогиниться, но он еще не может быть активным