Те тебе ок что для блокирующих операций тебе надо поднять кучу контейнеров которые будут в идле?

Те тебе ок что для блокирующих операций тебе надо поднять кучу контейнеров которые будут в идле?

а они не будут в идле

в идле останется только один

остальные умрут за ненадобностью и высвободят ресурсы класстера)

Те тебе ок что для блокирующих операций тебе надо поднять кучу контейнеров которые будут в идле?

а тебе ок, что будет куча процессов?

ну а если у меня стабильный поток сообщений - будет крутиться пул контейнеров минимальный

с точки зрения ресурсов - в целом одинаково

с точки зрения биллинга - выгодно контейнер=процесс (потому что ресурсы высвобождать проще/гибче)

Хорошо, да пример

если у тебя блокирующие слипы, пиши неблокирующий воркер

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

У тебя одна Джоба = послать мессагу по сети, время ответа 10 сек, загруз цпу = 0, пришло 1000 джобов

если у тебя блокирующие слипы, пиши неблокирующий воркер

если у тебя блокирующие слипы то весь этот разговор в целом абсурд ибо 80% времени все твои воркеры будут простаивать вне зависимости от выбранной стратегии

У тебя одна Джоба = послать мессагу по сети, время ответа 10 сек, загруз цпу = 0, пришло 1000 джобов

корутины?)

А я про что?)

окей, теперь понятно. у тебя воркер это корутина. Ну мол... ты можешь в одном процессе много задач обрабатывать. Тогда все одинаково и мы об одном и том же

И я про то же)

сорян тогда за недопонимание)

Само собой балансировать количество процессов в контейнере это путь в никуда)

просто непривычно в php чате за корутиты говорить(

обычно о них говорят в контекте "а что это такое?")

Лол, а мы уже привыкли)

просто непривычно в php чате за корутиты говорить(

тебя @zloyuser ещё не покусал что ли?)

он мне пока слегка напоил но до покусывание не дошло еще

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

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

один)

и скейли контейнерами

ну я бы два дал бы :)

с барского плеча прям

Кто больше? :)

пять!

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

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

Больше одного нет смысла

в пхп есть треды :)

не, лучше не стоит)

есть, но нет возможности раскидывать корутины по тредам

Есть, никто же не спорит

есть, но нет возможности раскидывать корутины по тредам

Есть

есть, но нет возможности раскидывать корутины по тредам

amphp/parallel

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

Но толку мало

amphp/parallel

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

Тут вам не го :)

или элексир/эрланг)

Именно

Это просто разный класс задач

Корутины нужны когда много io

Трэды когда cpu heavy

Но кто в здравом уме бужет делать cpu heavy на php?

когда cpu heavy + можно паралелить в рамках одной операции

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

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

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

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

так что даже среди любителей Java/C++ разработчики которые могут эффективно треды юзать это редкость. И задачи тоже редкие

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

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

всегда найдется азиат который делает "это" лучше

когда начнёшь знать про нагрузки, выйдешь из этого чатика)

меня и так тут нет :)

Весело было решать задачу по обработке видео с фиксированным временем ожидания) тут CPU выжирается на 100 при любом раскладе

вряд ли ты видео на пхп обрабатывал)

Нет конечно)

На пхп апи крутится

https://wiki.php.net/rfc/namespace-visibility

как-то упустил, хочу

https://wiki.php.net/rfc/namespace-visibility

инстедофы никуда не денутся(

инстедофы никуда не денутся(

?

Кто?

insteadof для трейтов

я как вспомню в ларке use macroAbleCall insteadof __call

ух

insteadof для трейтов

ммм... не юзаю трейты и не испытываю в них необходимости. А вот убрать геттеры для некоторых вещей мне эта штука позволит)

и сделать более явные взаимоотношения между элементами модулей

как тебе такое илон маск)

это AR модель от которой все модели в ларке наследуются)

каждый из трейтов на 1000+ строк

как тебе такое илон маск)

https://www.tbgclan.com/data/avatars/l/9/9725.jpg?1425508486

каждый из трейтов на 1000+ строк

да я видел)

придумай мне лучше задачку не оч большую где "ну без орм никак ваще"

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

придумай мне лучше задачку не оч большую где "ну без орм никак ваще"

любая штука где database first ?

а погодь

любая orm ar/dm ?

да, пофигу

что-то что бы ты не делал без ORM)

имея на руках дамп бд

я бы не создавал ентити сам

а сдифал бы их

все с нуля

мне это для эксперементов нужно

получается если у тебя изначально нет кучи говна ORM и не нужны

так, еще раз - я не интересуюсь когда они нужны а когда нет)

мне интересно услышать идею пет проджекта которую бы ты лично не делал бы без ORM)

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

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

каталог товаров с фильтрами разными по разным категориям подходит? просто хотелось бы что-то поменьше...